Re: [PATCH 26/28] hazptr: Implement two-phase wildcard scan

[Gary Guo]

On Sat Sep 19, 2026 at 1:00 AM BST, Paul E. McKenney wrote:
> From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx>
>
> Implement a two-phase wildcard scan to guarantee forward progress of
> synchronize_hazptr() even if there is a steady stream of ill-timed
> readers which populate wildcards into per-CPU slots.

Hmm, I am not sure that I understand the problem here. The per-CPU slot is
scanned only once per CPU, and patch 1 already introduces flipping of the
overflow list. What prevents the forward progress?

I think having a shared global read by all CPUs sounds really undesirable,
especially that it gets flipped for each hazptr_synchronize -- this means that
in the pathological case where there are a steady stream of hazptr_synchronize
calls, each fast-path hazptr_acquire will have a cache miss reading
hazptr_wildcard.

Best,
Gary

>
> This is performed by flipping between two wildcard values (1UL and 2UL),
> and alternatively scanning for the opposite wildcard while newcoming
> readers use the other one.
>
> There is no possibility to miss a reader because all slots for all
> wildcards are accounted for during a synchronize.
>
> As a simplification, use this period flip to drive the hazptr overflow
> list selection as well, since there is really no point is making the
> overflow list flip use a different state.
>
> Protect the wildcard flip with a mutex.
>
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx>
> Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxx>
> Cc: Boqun Feng <boqun@xxxxxxxxxx>
> Reviewed-by: Bradley Morgan <include@xxxxxxxxx>
> ---
>  include/linux/hazptr.h |  6 ++-
>  kernel/hazptr.c        | 98 ++++++++++++++++++++++++++++++------------
>  2 files changed, 74 insertions(+), 30 deletions(-)