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

["Gary Guo" <gary@garyguo.net>]

On Fri Sep 25, 2026 at 8:19 PM BST, Mathieu Desnoyers wrote:
> On 2026-09-20 11:57, Gary Guo wrote:
>> On Sun Sep 20, 2026 at 4:44 PM BST, Mathieu Desnoyers wrote:
>>>
>>> There is a straightforward optimization we can do if this happen to
>
>> Another option would be avoid using WILDCARD if possible. IIRC the wildcard is
>> used to ensure forward progress on the reader side, so it avoids the possibility
>> of READ_ONCE(*addr_p) changing before and after protecting.
>
> Using the wildcard has a few benefits:
>
> 1) Prevents this retry loop on the read-side.
>
> 2) Prevents comparison of a loaded pointer value against a re-load of
>     that value, which causes issues with compiler optimizations (I did a
>     ptr_eq() patch in a prior version of the hazard pointer patches to
>     handle this).

FWIW, clang is getting better with understanding pointer provenance now (see
https://github.com/llvm/llvm-project/issues/34577). There's still the case that
if one pointer being compared is a constant global or null, then the replacement
still happens, but it's not applicable for the hazptr case.

That said, this doesn't negate the need of having ptr_eq for GCC and old version
of Clang. I do agree that the need of ptr_eq is quite unfortunate.

>
> It does have a downside though: given a very long preemption by a host
> VM, the guest VM could technically keep a wildcard present for a long
> time in a per-cpu slot, which would prevent hazptr synchronize from
> progressing for a long time in the guest VM kernel.
>
>> 
>> One option would be to first use the typical hazard pointer impl that read the
>> pointer twice, and when that fails, use the wildcard protection. This would mean
>> that in the common case where the hazptr_acquire does not race with a pointer
>> update, the WILDCARD protection is not used at all.
>
> So your idea is to use the hazptr load+reload approach (with ptr_eq()
> check preventing the compiler from removing the dependency on the
> second load), but rather than retry, fallback to the two-phases
> wildcard. This way, we get the best of both worlds: guaranteed
> progress for the read-side (with the wildcard fallback), and typically
> we are immune to long-host-VM preemption delays, because the
> wildcard fallback would almost never fire.

Correct.

Perhaps we can take the idea further: what if the fallback path always insert
into backup list? As the backup list uses already uses two lists to ensure
forward progress, we only need a single WILDCARD?

Best,
Gary

>
> I like it. What do you guys think ?
>
> Thanks,
>
> Mathieu
>