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 >
