Re: [PATCH hazptr 0/4] Hazard pointer updates

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

On 2026-09-27 12:33, Bradley Morgan wrote:
> On 27 September 2026 17:27:33 BST, Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
>> On 2026-09-27 12:07, Bradley Morgan wrote:
>>> On 27 September 2026 16:51:27 BST, Mathieu Desnoyers
>>> <mathieu.desnoyers@efficios.com> wrote:
>>>> Hi Paul,
>>>>
>>>> This series applies on top of "hazptr: handle NULL address in
>>>> hazptr_detach" you have in your rcu dev tree.
>>>>
>>>> This first patch addresses a race identified by Boqun Feng in the
>>>> two-phase wildcard scheme.
>>>>
>>>> Patches 2-3 are prerequisites for using ptr_eq() in the 4th patch.
>>>> Those were discussed at length in a prior version of hazard pointer
>>>> patches.
>>>>
>>>> Patch 4 introduces a "try acquire" helper to allow the fast path
>>>> to not rely on wildcards, while keeping the wildcard forward
>>>> progress guarantees in the acquire slow path, used on fast path
>>>> failure.
>>>
>>> Hi, here is a hazptr perf test on powerpc
>>>
>>> REAL kill_fasync(), ns per call, best of 3, 100k calls:
>>> (stock = rwlock walk, conv = hazptr walk, same v3 tree ± the conversion)
>>>
>>>     shape          stock    conv     delta
>>>     1 node,  1 walker     59      59     +0.0%   (singleton: identical)
>>>     16 nodes, 1 walker   539     539     +0.0%   (uncontended: identical)
>>>     16 nodes, 4 walkers  509     134    -73.7%   ← rwlock readers contend
>>>     16 nodes, 8 walkers  313     113    -63.9%   ← same list, 8 cpus
>>>     64 nodes, 1 walker  1979    2039     +3.0%   (pure walk: hazptr tax)
>>>     64 nodes, 4 walkers 1914     509    -73.4%
>>>     64 nodes, 8 walkers 1015     382    -62.4%
>>>
>>> Its SLOWER than rcu, but beats rwlock
>>
>> Two feedback points:
>>
>> 1) The comparison I think Boqun cares mostly about is with expedited
>>    RCU grace periods, this is where we suspect there is a significant
>>    benefit to using hazptr rather than RCU to eliminate those IPIs
>>    on synchronize.
>>
>>    It's good to know that it performs better than rwlock (albeit it's
>>    not surprising).
>>
>> 2) I'm concerned about what looks like a use of hazptr to protect linked
>>    lists elements in your benchmark (did I miss anything ?).
>>
>>    RCU read-side critical sections protect all elements of a linked list
>>    naturally, but hazptr requires more care. See this comment above
>>    hazptr_acquire:
>>
>> * This protection is unconditional, and has limitations similar to
>> * that of unconditional reference-counter acquisition.  In particular,
>> * although holding a hazard pointer prevents a hazard-pointer-protected
>> * object from being freed, it does not prevent that object from being
>> * removed from a linked data structure, and does not prevent other
>> * hazard-pointer-protected objects referenced by this object from being
>> * both removed and freed.  At which point, invoking hazptr_acquire()
>> * on these dangling pointers would be a bug.  On the other hand, use of
>> * hazptr_acquire() is safe for immortal pointers to objects that do not
>> * themselves contain pointers to hazard-pointer-protected objects.
>> * Other (more complex) use cases are also possible.
>>
>> Does the pointer you protect qualify as an "immortal" pointer, or it's
>> a linked list "next" pointer ?
>>
> 
> Hmm. Do you have a idea on what you could metaphorically convert, with a
> core subsystem?
> 
> I'll give anything you want me to do a try
At a high level, I suspect it would be good to start by digging into
users of synchronize_rcu_expedited(), to see if a few of those may be
good candidates.

I would also favor scenarios where RCU (or locking) are used to protect
the existence of an object reachable from a global pointer, and use
hazptr to protect that object. Note that initially this precludes
a hazptr-protected list, because the next pointers would sit in
prior objects which are themselves hazptr-protected, which is not
sufficient to guarantee existence against a hand in hand traversal.

However, if you have a pointer to an object "side-car" structure
(e.g. optional extra metadata), and the object containing the pointer
is guaranteed to exist by another mechanism (e.g. RCU, locking), then
that pointer-to-side-car-object field would be a good candidate for
hazptr (AFAIU).

I'm not saying the linked lists could not be done, but it would require
more care.

Thanks,

Mathieu

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