On Sun, Sep 06, 2026 at 07:56:29PM +0100, Bradley Morgan wrote:
> On 6 September 2026 19:46:50 BST, "Paul E. McKenney" <[email protected]>
> wrote:
> >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!
> >
> Can I participate in this? :)
If Mathieu is OK with it, feel free to look at the patch stack that
Mathieu sent the URL for earlier in this thread. Either way, please
feel free to look at the stack in my -rcu tree based on v7.3-rc1 and
headed by this commit:
4398b7c192d ("hazptr: Implement two-phase wildcard scan")
Perhaps you can find the bug that kernel test robot located. ;-)
My -rcu tree is here:
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
Just so you know, in all cases, your taking on a task does not preclude
others from also taking that same task on.
Thanx, Paul
> --- Thanks!
> https://lore.kernel.org/all/[email protected]/
