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

[Gary Guo]

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@xxxxxxxxxx/ 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@xxxxxxxxx/
>> 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@xxxxxxxxxx/

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