On Sun, Sep 27, 2026 at 01:15:39PM -0400, Mathieu Desnoyers wrote:
[...]
> > > @@ -196,16 +197,13 @@ void hazptr_scan_cpu_slots_period(void *addr, void
> > > *scan_wildcard)
> > > for_each_possible_cpu(cpu) {
> > > /*
> > > * Scan CPU slots.
> > > - * Forward progress against recurring wildcards is guaranteed
> > > - * by scanning for one wildcard while new elements use the
> > > - * other wildcard value (1UL vs 2UL).
> > > * Forward progress against recurring single hazard
> > > pointer
> > > * values is guaranteed by the fact that a hazard
> > > pointer
> > > * is not reclaimed nor reused until the scan for that
> > > hazard
> > > * pointer completes, which prevents a steady flow of
> > > readers
> > > * to acquire that same hazard pointer value.
> >
> > (Not a comment to this patch, but I think it's worth bringing up)
> >
> > 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 ?
>
No, you got it right, but as I said, we can use it in lockdep since the
readers are relatively rare, so not an issue here.
> One honest question: is this pattern something we expect to
> see often ? If so, then we may want to introduce a notion of
I honestly don't know. But in my opinion, we'd better focus on finding
more typical usage of hazptr (i.e. protecting actual object). So ...
> 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.
>
> Thoughts ?
>
... I will say let's add it only if we have more users of this pattern.
Regards,
Boqun
> Thanks,
>
> Mathieu
>
> >
> > The rest looks good to me.
> >
> > Regards,
> > Boqun
> >
>
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> https://www.efficios.com
