Re: [PATCH RFC v3 08/15] locking/lockdep: use hazptr to wait for dynamic key lookups

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

On 2026-10-13 08:48, Boqun Feng wrote:
> On Tue, Oct 13, 2026 at 03:40:36PM +0800, Lai Jiangshan wrote:
[...]
>>
>> This breaks the forward-progress argument used by the underlying
>> hazptr implementation: after removing an object from publication,
>> there should not be a continuing stream of new readers acquiring
>> that same object. Here, the bucket is never unpublished.
>>
>> For example, let B be the bucket containing key K:
>>
>>    Updater                    Reader                 Scan kthread
>>    -------                    ------                 ------------
>>    Unlink K from B
>>    hazptr_synchronize(B)
>>                               Acquire B
>>                                                      Observe B;
>>                                                      retain waiter
>>                               Release B
>>                               Acquire B again
>>                                                      Observe B;
>>                                                      retain waiter
>>                               Release B
>>                               ...                    ...
>>
> 
> This is more of an implementation issue,
I agree with Boqun about the point that this is really an implementation
issue.

If we care about forward progress in the scenario of a repeated
address reuse, we just need to wire up a "0/1" low bit phase tag and
make hazptr acquire pick it up and set it within its hazptr slot. This
will ensure forward progress in that scenario. hazptr synchronzie
would therefore flip this phase between 0 and 1, and check that the
pointer it's looking for is not set in the other phase, in alternance,
handling both phases within one synchronize. Indeed, this phase concept
comes from the realm of RCU implementations.

I think that the overall mindset so far has been "RCU does this" and
"Hazard pointers do this" as if those were entirely predefined
mechanisms. I think the way forward is not "one or the other", but
rather to combine the strengths of each of those mechanisms into
something better.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com