On Sun, Sep 27, 2026 at 12:45:10PM -0400, Mathieu Desnoyers wrote:
> On 2026-09-27 12:33, Bradley Morgan wrote:
> > On 27 September 2026 17:27:33 BST, Mathieu Desnoyers
> > <[email protected]> wrote:
> > > On 2026-09-27 12:07, Bradley Morgan wrote:
> > > > On 27 September 2026 16:51:27 BST, Mathieu Desnoyers
> > > > <[email protected]> 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.
Other candidates include users of per-CPU reference counters, along with
any try-acquire reference counters that have seen memory contention.
Thanx, Paul
