On 28 September 2026 12:32:34 BST, Gary Guo <[email protected]> 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/[email protected]/
>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/[email protected]/
>>> 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/[email protected]/
>
>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
