Re: [PATCH] hazptrtorture: Fix inverted sleep condition in do_pending kthread

[Bradley Morgan]

On 7 September 2026 00:16:55 BST, "Paul E. McKenney" <paulmck@xxxxxxxxxx>
wrote:
>On Sun, Sep 06, 2026 at 07:56:29PM +0100, Bradley Morgan wrote:
>> On 6 September 2026 19:46:50 BST, "Paul E. McKenney"
><paulmck@xxxxxxxxxx>
>> 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/EE579805-42F2-4C58-B752-F28779EEB717@xxxxxxxxx/
>> >> 
>> >> 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/202608130915.62b53936-lkp@xxxxxxxxx/
>> >
>> >> > 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/20251218014531.3793471-1-mathieu.desnoyers@xxxxxxxxxxxx/
>> >
>> >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/EE579805-42F2-4C58-B752-F28779EEB717@xxxxxxxxx/
Hey, test this fix?