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!
>
> Thanx, Paul
Can I participate in this? :)
--- Thanks!
https://lore.kernel.org/all/[email protected]/
