Re: [PATCH hazptr 4/4] hazptr: Introduce "try acquire" fast path, fallback to overflow list

[Boqun Feng <boqun@kernel.org>]

On Sun, Sep 27, 2026 at 11:39:00PM +0100, Gary Guo wrote:
> On Sun Sep 27, 2026 at 6:15 PM BST, Mathieu Desnoyers wrote:
> > On 2026-09-27 12:40, Boqun Feng wrote:
> >
> >> I want to point out this is not true for the lockdep use case, because
> >> the we need to protect a hash list deletion there, and we use the
> >> address of the hash bucket there. It's proven fine in practice because
> >> the readers are rare (we only call the reader is_dynamic_key() in
> >> register_lock_class(), that is every time you have a new lock class to
> >> register).
> >> 
> >> Maybe what we want to say here is that "if the users guarantee no steady
> >> flow of the same hazard pointer value, we guarantee forward progress".
> >> Thoughts?
> >
> > AFAIU, your approach to protect lockdep linked lists is to use the
> > address of the hash bucket to protect the traversal. As this address is 
> > invariant (global array item address), that address should be fine
> > to fulfill hazptr requirements, but it has downsides: rather than
> > protecting the specific nodes being retired, the whole hash chain is
> > protected. This means that, as you point out, many readers retiring
> > nodes from a given bucket (except the first node) could end up holding a
> > continuous stream of hazptr for a given hazptr value, preventing
> > progress of hazptr synchronize.
> >
> > It's also coarser: per-bucket rather than per-node.
> >
> > Am I missing something here ?
> >
> > One honest question: is this pattern something we expect to
> > see often ? If so, then we may want to introduce a notion of
> > hazptr protection "period" flip (similar to some RCU implementations),
> > where we tag the low bit of the slot pointer (0 vs 1), and alternate
> > between the two periods in synchronize. This would prevent a steady-flow
> > of same-value readers from preventing synchronize forward progress.
> 
> Slightly off topic, but I have a use-case in mind (in case you're not already
> aware) where the address is fixed like the lockdep class, but it does not suffer
> the forward progress guarantee.
> 
> I have been wanting to use hazptr for revocable for quite a while (I think I
> chatted with Boqun about this last LPC). For the revocable use case, the
> protected pointer is fixed, however there is an additional boolean flag to
> determine if the resource been revoked or not.
> 
> Something like this:
> 
>     void *revocable_try_access(struct revocable *rev) {
>         struct hazptr_ctx ctx = {};
>         if (READ_ONCE(rev->revoked))
>             return NULL;
>         // note the & cancels out with the * in acquire, so the address is fixed.
>         hazptr_acquire(&ctx, &rev);
>         if (READ_ONCE(rev->revoked))
>             return NULL;
>         return rev->res;
>     }
> 
>     void revocable_revoke(struct revocable *rev) {
>         WRITE_ONCE(rev->revoked, true);
>         hazptr_synchronize(&rev);
>     }
> 
> So while the address is fixed, we have a different field to do the unpublishing
> part.
> 
> For some context, the current Rust revocable implementation uses RCU, but this
> is limiting the case where it can be used. The current C revocable series in
> https://lore.kernel.org/all/20260912123529.7951-1-tzungbi@kernel.org/ uses SRCU.
> 
> I think this use case is a good one for hazptr, in fact, I have encouraged Alvin
> Sun to try it out and you can see an implementation (Rust) in here:
> https://lore.kernel.org/rust-for-linux/20260326-b4-tyr-debugfs-v1-6-074badd18716@linux.dev/
> Although, over the course of the year, we have been reducing the amount of
> revocable usage and shifting to represent things with lifetime..
> 

Paul asked me for the Rust usage a few days ago, and since we moved to
a lifetime based approach [1], which is better IMO, I don't think
switching to hazptr will should observable difference here, especially
for a real workload improvement. It's still worth trying to see how
hazptr in Rust would work for this, but it's less a sufficient condition
to merge hazptr from my understanding. Of course I could be wrong.

[1]: https://lore.kernel.org/rust-for-linux/20260517000149.3226762-1-dakr@kernel.org/

Regards,
Boqun

Regards,
Boqun

> Best,
> Gary