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

[Bradley Morgan <brads@mainlining.org>]

On 28 September 2026 12:32:34 BST, Gary Guo <gary@garyguo.net> wrote:
>On Mon Sep 28, 2026 at 10:12 AM BST, Boqun Feng wrote:
>> 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/
>
>What we get rid of is to use `Revocable` (or `DevRes`) to protect
>resources
>where we _know_ that the resource is alive (for example, in device private
>data,
>because it's teared down by driver-core on unbind).
>
>However, there are cases where we can still have the `Revocable` pattern,
>for
>example when a class device is exposed to userspace and the bus device is
>unbinding. This is a pretty recurring pattern too, and cannot be handled
>via
>lifetime alone. This is what motivates the C revocable series.
>
>Best,
>Gary
>
Would you like me to try and draft a hazptr rust file? I mean, I'm not a
expert at it, but I'll throw my hat into the ring 
--- Thanks!
"I'm not a very positive person" - Linus torvalds