On Sun, Sep 06, 2026 at 09:09:53AM -0400, Mathieu Desnoyers wrote: > On 2026-09-05 16:40, Paul E. McKenney wrote: > > On Fri, Sep 04, 2026 at 06:28:45PM +0100, Bradley Morgan wrote: > [...] > > I would not say "no" to a fix for this issue: > > > > https://lore.kernel.org/all/[email protected]/ > > I'm not sure this URL actually points to a relevant issue ?
Indeed, it does not, apologies! Here you go: https://lore.kernel.org/all/[email protected]/ > > Once that is in place, I would be happy to put this back into -next. > > > > At some point, we will need to get rid of the concept of wildcard hazard > > pointers, as those end up instead emulating RCU, but I don't see that > > as an immediate obstacle. > > I already have the implementation which eliminates the wildcard if we > care about this. It was part of a previous hazptr series version. > > Do you want me to resurrect it on top of the current series ? > This depends on: > > - ptr_eq(), > - then use ptr_eq() to compare the loaded pointer (pre mb) > with the re-loaded pointer (post-mb). > > See: > https://lore.kernel.org/all/[email protected]/ The main objection was over the content and style of the kernel-doc header comment, right? I am guessing that it should be possible to resolve this to roughly equal disgust of all concerned. ;-) We did make some progress on this sort of pointer issue in C++29 this past June: https://people.kernel.org/paulmck/c-pointer-zap-and-oota-progress But the piece you need is this guy, which is still in process: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3790r1.pdf Plus it will be some time before this reaches all the compilers used to build the Linux kernel, and probably even more time to reach the C language. I do have pen-on-paper notes that will lead to a draft of the corresponding C-language working paper, but these things do not move quickly. So, yes, we will need something like ptr_eq() for some years to come. Back to your original question, given the fix for the above bug and given the current use case, I believe we can get the current series into mainline. Give or take Linus's thoughts on the matter. But either way, we will need a version that allows the user to avoid all wildcard use sooner rather than later. So having a series on top of the current one for a later merge window would be a very good thing! Thanx, Paul
