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

[Gary Guo]

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..

Best,
Gary