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

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

[Bradley Morgan]

The do_pending kthread never sleeps. Its supposed to.
kthread_do_pending_ms sets the gap between cleanups, and the docs
say so too. But the sleep sits behind torture_must_stop(), and thats
false while the test runs. So the kthread never sleeps. It just loops.
It drains the pending lists over and over, no pause, and burns a full
CPU for the whole test.

Flip the check. With !torture_must_stop() it sleeps for
kthread_do_pending_ms between passes. When the test stops it does one
last cleanup and exits. Nothing left to do, so no sleep needed then.

Fixes: 94d2e93c222e ("hazptrtorture: Add kthread to release deferred hazard pointers")
Signed-off-by: Bradley Morgan <include@grrlz.net>
---
 kernel/rcu/hazptrtorture.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/rcu/hazptrtorture.c b/kernel/rcu/hazptrtorture.c
index 72aeb50668e9..7c8b5899fb01 100644
--- a/kernel/rcu/hazptrtorture.c
+++ b/kernel/rcu/hazptrtorture.c
@@ -555,7 +555,7 @@ static int hazptr_torture_do_pending(void *arg)
 			cpu = cpumask_next_wrap(cpu, cpu_possible_mask);
 			hazptr_torture_do_one_pending(cpu, &rand);
 		}
-		if (torture_must_stop())
+		if (!torture_must_stop())
 			torture_hrtimeout_ms(kthread_do_pending_ms, USEC_PER_MSEC, &rand);
 		// Omit stutter_wait() because this function needs to do cleanup.
 	} while (!torture_must_stop());
-- 
2.47.3

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

[Paul E. McKenney]

On Tue, Aug 04, 2026 at 12:03:39AM +0000, Bradley Morgan wrote:
> The do_pending kthread never sleeps. Its supposed to.
> kthread_do_pending_ms sets the gap between cleanups, and the docs
> say so too. But the sleep sits behind torture_must_stop(), and thats
> false while the test runs. So the kthread never sleeps. It just loops.
> It drains the pending lists over and over, no pause, and burns a full
> CPU for the whole test.
> 
> Flip the check. With !torture_must_stop() it sleeps for
> kthread_do_pending_ms between passes. When the test stops it does one
> last cleanup and exits. Nothing left to do, so no sleep needed then.
> 
> Fixes: 94d2e93c222e ("hazptrtorture: Add kthread to release deferred hazard pointers")
> Signed-off-by: Bradley Morgan <include@grrlz.net>

Good catch, applied, thank you!

							Thanx, Paul

> ---
>  kernel/rcu/hazptrtorture.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/rcu/hazptrtorture.c b/kernel/rcu/hazptrtorture.c
> index 72aeb50668e9..7c8b5899fb01 100644
> --- a/kernel/rcu/hazptrtorture.c
> +++ b/kernel/rcu/hazptrtorture.c
> @@ -555,7 +555,7 @@ static int hazptr_torture_do_pending(void *arg)
>  			cpu = cpumask_next_wrap(cpu, cpu_possible_mask);
>  			hazptr_torture_do_one_pending(cpu, &rand);
>  		}
> -		if (torture_must_stop())
> +		if (!torture_must_stop())
>  			torture_hrtimeout_ms(kthread_do_pending_ms, USEC_PER_MSEC, &rand);
>  		// Omit stutter_wait() because this function needs to do cleanup.
>  	} while (!torture_must_stop());
> -- 
> 2.47.3
> 

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

[Mathieu Desnoyers]

On 2026-08-03 20:03, Bradley Morgan wrote:
> The do_pending kthread never sleeps. Its supposed to.
> kthread_do_pending_ms sets the gap between cleanups, and the docs
> say so too. But the sleep sits behind torture_must_stop(), and thats
> false while the test runs. So the kthread never sleeps. It just loops.
> It drains the pending lists over and over, no pause, and burns a full
> CPU for the whole test.

Paul, I just found this patch in my junk email folder. Maybe relevant
for you ?

Thanks,

Mathieu

> 
> Flip the check. With !torture_must_stop() it sleeps for
> kthread_do_pending_ms between passes. When the test stops it does one
> last cleanup and exits. Nothing left to do, so no sleep needed then.
> 
> Fixes: 94d2e93c222e ("hazptrtorture: Add kthread to release deferred hazard pointers")
> Signed-off-by: Bradley Morgan <include@grrlz.net>
> ---
>   kernel/rcu/hazptrtorture.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/rcu/hazptrtorture.c b/kernel/rcu/hazptrtorture.c
> index 72aeb50668e9..7c8b5899fb01 100644
> --- a/kernel/rcu/hazptrtorture.c
> +++ b/kernel/rcu/hazptrtorture.c
> @@ -555,7 +555,7 @@ static int hazptr_torture_do_pending(void *arg)
>   			cpu = cpumask_next_wrap(cpu, cpu_possible_mask);
>   			hazptr_torture_do_one_pending(cpu, &rand);
>   		}
> -		if (torture_must_stop())
> +		if (!torture_must_stop())
>   			torture_hrtimeout_ms(kthread_do_pending_ms, USEC_PER_MSEC, &rand);
>   		// Omit stutter_wait() because this function needs to do cleanup.
>   	} while (!torture_must_stop());


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

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

[Paul E. McKenney]

On Fri, Sep 04, 2026 at 09:01:05AM -0400, Mathieu Desnoyers wrote:
> On 2026-08-03 20:03, Bradley Morgan wrote:
> > The do_pending kthread never sleeps. Its supposed to.
> > kthread_do_pending_ms sets the gap between cleanups, and the docs
> > say so too. But the sleep sits behind torture_must_stop(), and thats
> > false while the test runs. So the kthread never sleeps. It just loops.
> > It drains the pending lists over and over, no pause, and burns a full
> > CPU for the whole test.
> 
> Paul, I just found this patch in my junk email folder. Maybe relevant
> for you ?

We got it in my -rcu tree:

15b9fca2f5ce ("hazptrtorture: Fix inverted sleep condition in do_pending kthread")

But I do appreciate your checking for missed patches, thank you!

							Thanx, Paul

> Thanks,
> 
> Mathieu
> 
> > 
> > Flip the check. With !torture_must_stop() it sleeps for
> > kthread_do_pending_ms between passes. When the test stops it does one
> > last cleanup and exits. Nothing left to do, so no sleep needed then.
> > 
> > Fixes: 94d2e93c222e ("hazptrtorture: Add kthread to release deferred hazard pointers")
> > Signed-off-by: Bradley Morgan <include@grrlz.net>
> > ---
> >   kernel/rcu/hazptrtorture.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/kernel/rcu/hazptrtorture.c b/kernel/rcu/hazptrtorture.c
> > index 72aeb50668e9..7c8b5899fb01 100644
> > --- a/kernel/rcu/hazptrtorture.c
> > +++ b/kernel/rcu/hazptrtorture.c
> > @@ -555,7 +555,7 @@ static int hazptr_torture_do_pending(void *arg)
> >   			cpu = cpumask_next_wrap(cpu, cpu_possible_mask);
> >   			hazptr_torture_do_one_pending(cpu, &rand);
> >   		}
> > -		if (torture_must_stop())
> > +		if (!torture_must_stop())
> >   			torture_hrtimeout_ms(kthread_do_pending_ms, USEC_PER_MSEC, &rand);
> >   		// Omit stutter_wait() because this function needs to do cleanup.
> >   	} while (!torture_must_stop());
> 
> 
> -- 
> Mathieu Desnoyers
> EfficiOS Inc.
> https://www.efficios.com

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

[Bradley Morgan]

On 4 September 2026 17:00:22 BST, "Paul E. McKenney" <paulmck@kernel.org>
wrote:
>On Fri, Sep 04, 2026 at 09:01:05AM -0400, Mathieu Desnoyers wrote:
>> On 2026-08-03 20:03, Bradley Morgan wrote:
>> > The do_pending kthread never sleeps. Its supposed to.
>> > kthread_do_pending_ms sets the gap between cleanups, and the docs
>> > say so too. But the sleep sits behind torture_must_stop(), and thats
>> > false while the test runs. So the kthread never sleeps. It just loops.
>> > It drains the pending lists over and over, no pause, and burns a full
>> > CPU for the whole test.
>> 
>> Paul, I just found this patch in my junk email folder. Maybe relevant
>> for you ?
>
>We got it in my -rcu tree:
>
>15b9fca2f5ce ("hazptrtorture: Fix inverted sleep condition in do_pending
>kthread")
>
>But I do appreciate your checking for missed patches, thank you!
>
>							Thanx, Paul
>
>> Thanks,
>> 
>> Mathieu
>> 
>> > 
>> > Flip the check. With !torture_must_stop() it sleeps for
>> > kthread_do_pending_ms between passes. When the test stops it does one
>> > last cleanup and exits. Nothing left to do, so no sleep needed then.
>> > 
>> > Fixes: 94d2e93c222e ("hazptrtorture: Add kthread to release deferred
>hazard pointers")
>> > Signed-off-by: Bradley Morgan <include@grrlz.net>
>> > ---
>> >   kernel/rcu/hazptrtorture.c | 2 +-
>> >   1 file changed, 1 insertion(+), 1 deletion(-)
>> > 
>> > diff --git a/kernel/rcu/hazptrtorture.c b/kernel/rcu/hazptrtorture.c
>> > index 72aeb50668e9..7c8b5899fb01 100644
>> > --- a/kernel/rcu/hazptrtorture.c
>> > +++ b/kernel/rcu/hazptrtorture.c
>> > @@ -555,7 +555,7 @@ static int hazptr_torture_do_pending(void *arg)
>> >   			cpu = cpumask_next_wrap(cpu, cpu_possible_mask);
>> >   			hazptr_torture_do_one_pending(cpu, &rand);
>> >   		}
>> > -		if (torture_must_stop())
>> > +		if (!torture_must_stop())
>> >   			torture_hrtimeout_ms(kthread_do_pending_ms, USEC_PER_MSEC, &rand);
>> >   		// Omit stutter_wait() because this function needs to do cleanup.
>> >   	} while (!torture_must_stop());
>> 
>> 
>> -- 
>> Mathieu Desnoyers
>> EfficiOS Inc.
>> https://www.efficios.com
>
>
Hi, new email.

Could I ask where the heck hazptr is? Its not in next, would you like,
help???

--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

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

[Paul E. McKenney]

On Fri, Sep 04, 2026 at 06:28:45PM +0100, Bradley Morgan wrote:
> On 4 September 2026 17:00:22 BST, "Paul E. McKenney" <paulmck@kernel.org>
> wrote:
> >On Fri, Sep 04, 2026 at 09:01:05AM -0400, Mathieu Desnoyers wrote:
> >> On 2026-08-03 20:03, Bradley Morgan wrote:
> >> > The do_pending kthread never sleeps. Its supposed to.
> >> > kthread_do_pending_ms sets the gap between cleanups, and the docs
> >> > say so too. But the sleep sits behind torture_must_stop(), and thats
> >> > false while the test runs. So the kthread never sleeps. It just loops.
> >> > It drains the pending lists over and over, no pause, and burns a full
> >> > CPU for the whole test.
> >> 
> >> Paul, I just found this patch in my junk email folder. Maybe relevant
> >> for you ?
> >
> >We got it in my -rcu tree:
> >
> >15b9fca2f5ce ("hazptrtorture: Fix inverted sleep condition in do_pending
> >kthread")
> >
> >But I do appreciate your checking for missed patches, thank you!
> >
> >							Thanx, Paul
> >
> >> Thanks,
> >> 
> >> Mathieu
> >> 
> >> > 
> >> > Flip the check. With !torture_must_stop() it sleeps for
> >> > kthread_do_pending_ms between passes. When the test stops it does one
> >> > last cleanup and exits. Nothing left to do, so no sleep needed then.
> >> > 
> >> > Fixes: 94d2e93c222e ("hazptrtorture: Add kthread to release deferred
> >hazard pointers")
> >> > Signed-off-by: Bradley Morgan <include@grrlz.net>
> >> > ---
> >> >   kernel/rcu/hazptrtorture.c | 2 +-
> >> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >> > 
> >> > diff --git a/kernel/rcu/hazptrtorture.c b/kernel/rcu/hazptrtorture.c
> >> > index 72aeb50668e9..7c8b5899fb01 100644
> >> > --- a/kernel/rcu/hazptrtorture.c
> >> > +++ b/kernel/rcu/hazptrtorture.c
> >> > @@ -555,7 +555,7 @@ static int hazptr_torture_do_pending(void *arg)
> >> >   			cpu = cpumask_next_wrap(cpu, cpu_possible_mask);
> >> >   			hazptr_torture_do_one_pending(cpu, &rand);
> >> >   		}
> >> > -		if (torture_must_stop())
> >> > +		if (!torture_must_stop())
> >> >   			torture_hrtimeout_ms(kthread_do_pending_ms, USEC_PER_MSEC, &rand);
> >> >   		// Omit stutter_wait() because this function needs to do cleanup.
> >> >   	} while (!torture_must_stop());
> >> 
> >> 
> >> -- 
> >> Mathieu Desnoyers
> >> EfficiOS Inc.
> >> https://www.efficios.com
> >
> >
> Hi, new email.
> 
> Could I ask where the heck hazptr is? Its not in next, would you like,
> help???
> 
> --- Thanks!
> https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

It is still in my -rcu tree.

I would not say "no" to a fix for this issue:

https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

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.

							Thanx, Paul

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

[Bradley Morgan]

On 5 September 2026 21:40:28 BST, "Paul E. McKenney" <paulmck@kernel.org>
wrote:
>On Fri, Sep 04, 2026 at 06:28:45PM +0100, Bradley Morgan wrote:
>> On 4 September 2026 17:00:22 BST, "Paul E. McKenney"
><paulmck@kernel.org>
>> wrote:
>> >On Fri, Sep 04, 2026 at 09:01:05AM -0400, Mathieu Desnoyers wrote:
>> >> On 2026-08-03 20:03, Bradley Morgan wrote:
>> >> > The do_pending kthread never sleeps. Its supposed to.
>> >> > kthread_do_pending_ms sets the gap between cleanups, and the docs
>> >> > say so too. But the sleep sits behind torture_must_stop(), and
>thats
>> >> > false while the test runs. So the kthread never sleeps. It just
>loops.
>> >> > It drains the pending lists over and over, no pause, and burns a
>full
>> >> > CPU for the whole test.
>> >> 
>> >> Paul, I just found this patch in my junk email folder. Maybe relevant
>> >> for you ?
>> >
>> >We got it in my -rcu tree:
>> >
>> >15b9fca2f5ce ("hazptrtorture: Fix inverted sleep condition in
>do_pending
>> >kthread")
>> >
>> >But I do appreciate your checking for missed patches, thank you!
>> >
>> >							Thanx, Paul
>> >
>> >> Thanks,
>> >> 
>> >> Mathieu
>> >> 
>> >> > 
>> >> > Flip the check. With !torture_must_stop() it sleeps for
>> >> > kthread_do_pending_ms between passes. When the test stops it does
>one
>> >> > last cleanup and exits. Nothing left to do, so no sleep needed
>then.
>> >> > 
>> >> > Fixes: 94d2e93c222e ("hazptrtorture: Add kthread to release
>deferred
>> >hazard pointers")
>> >> > Signed-off-by: Bradley Morgan <include@grrlz.net>
>> >> > ---
>> >> >   kernel/rcu/hazptrtorture.c | 2 +-
>> >> >   1 file changed, 1 insertion(+), 1 deletion(-)
>> >> > 
>> >> > diff --git a/kernel/rcu/hazptrtorture.c
>b/kernel/rcu/hazptrtorture.c
>> >> > index 72aeb50668e9..7c8b5899fb01 100644
>> >> > --- a/kernel/rcu/hazptrtorture.c
>> >> > +++ b/kernel/rcu/hazptrtorture.c
>> >> > @@ -555,7 +555,7 @@ static int hazptr_torture_do_pending(void *arg)
>> >> >   			cpu = cpumask_next_wrap(cpu, cpu_possible_mask);
>> >> >   			hazptr_torture_do_one_pending(cpu, &rand);
>> >> >   		}
>> >> > -		if (torture_must_stop())
>> >> > +		if (!torture_must_stop())
>> >> >   			torture_hrtimeout_ms(kthread_do_pending_ms, USEC_PER_MSEC, &rand);
>> >> >   		// Omit stutter_wait() because this function needs to do cleanup.
>> >> >   	} while (!torture_must_stop());
>> >> 
>> >> 
>> >> -- 
>> >> Mathieu Desnoyers
>> >> EfficiOS Inc.
>> >> https://www.efficios.com
>> >
>> >
>> Hi, new email.
>> 
>> Could I ask where the heck hazptr is? Its not in next, would you like,
>> help???
>> 
>> --- Thanks!
>>
>https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/
>
>It is still in my -rcu tree.
>
>I would not say "no" to a fix for this issue:
>
>https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/
>
>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.


Well, okay, tell me more and I'll develop it.

>
>							Thanx, Paul

--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

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

[Paul E. McKenney]

On Sat, Sep 05, 2026 at 10:08:30PM +0100, Bradley Morgan wrote:
> On 5 September 2026 21:40:28 BST, "Paul E. McKenney" <paulmck@kernel.org>
> wrote:
> >On Fri, Sep 04, 2026 at 06:28:45PM +0100, Bradley Morgan wrote:
> >> On 4 September 2026 17:00:22 BST, "Paul E. McKenney"
> ><paulmck@kernel.org>
> >> wrote:
> >> >On Fri, Sep 04, 2026 at 09:01:05AM -0400, Mathieu Desnoyers wrote:
> >> >> On 2026-08-03 20:03, Bradley Morgan wrote:
> >> >> > The do_pending kthread never sleeps. Its supposed to.
> >> >> > kthread_do_pending_ms sets the gap between cleanups, and the docs
> >> >> > say so too. But the sleep sits behind torture_must_stop(), and
> >thats
> >> >> > false while the test runs. So the kthread never sleeps. It just
> >loops.
> >> >> > It drains the pending lists over and over, no pause, and burns a
> >full
> >> >> > CPU for the whole test.
> >> >> 
> >> >> Paul, I just found this patch in my junk email folder. Maybe relevant
> >> >> for you ?
> >> >
> >> >We got it in my -rcu tree:
> >> >
> >> >15b9fca2f5ce ("hazptrtorture: Fix inverted sleep condition in
> >do_pending
> >> >kthread")
> >> >
> >> >But I do appreciate your checking for missed patches, thank you!
> >> >
> >> >							Thanx, Paul
> >> >
> >> >> Thanks,
> >> >> 
> >> >> Mathieu
> >> >> 
> >> >> > 
> >> >> > Flip the check. With !torture_must_stop() it sleeps for
> >> >> > kthread_do_pending_ms between passes. When the test stops it does
> >one
> >> >> > last cleanup and exits. Nothing left to do, so no sleep needed
> >then.
> >> >> > 
> >> >> > Fixes: 94d2e93c222e ("hazptrtorture: Add kthread to release
> >deferred
> >> >hazard pointers")
> >> >> > Signed-off-by: Bradley Morgan <include@grrlz.net>
> >> >> > ---
> >> >> >   kernel/rcu/hazptrtorture.c | 2 +-
> >> >> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >> >> > 
> >> >> > diff --git a/kernel/rcu/hazptrtorture.c
> >b/kernel/rcu/hazptrtorture.c
> >> >> > index 72aeb50668e9..7c8b5899fb01 100644
> >> >> > --- a/kernel/rcu/hazptrtorture.c
> >> >> > +++ b/kernel/rcu/hazptrtorture.c
> >> >> > @@ -555,7 +555,7 @@ static int hazptr_torture_do_pending(void *arg)
> >> >> >   			cpu = cpumask_next_wrap(cpu, cpu_possible_mask);
> >> >> >   			hazptr_torture_do_one_pending(cpu, &rand);
> >> >> >   		}
> >> >> > -		if (torture_must_stop())
> >> >> > +		if (!torture_must_stop())
> >> >> >   			torture_hrtimeout_ms(kthread_do_pending_ms, USEC_PER_MSEC, &rand);
> >> >> >   		// Omit stutter_wait() because this function needs to do cleanup.
> >> >> >   	} while (!torture_must_stop());
> >> >> 
> >> >> 
> >> >> -- 
> >> >> Mathieu Desnoyers
> >> >> EfficiOS Inc.
> >> >> https://www.efficios.com
> >> >
> >> >
> >> Hi, new email.
> >> 
> >> Could I ask where the heck hazptr is? Its not in next, would you like,
> >> help???
> >> 
> >> --- Thanks!
> >>
> >https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/
> >
> >It is still in my -rcu tree.
> >
> >I would not say "no" to a fix for this issue:
> >
> >https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/
> >
> >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.
> 
> Well, okay, tell me more and I'll develop it.

I must confess that I have not looked much into that bug report, so I
don't have much more to tell.

						Thanx, Paul

> --- Thanks!
> https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/
> 

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

[Bradley Morgan]

On 5 September 2026 23:54:38 BST, "Paul E. McKenney" <paulmck@kernel.org>
wrote:
>On Sat, Sep 05, 2026 at 10:08:30PM +0100, Bradley Morgan wrote:
>> On 5 September 2026 21:40:28 BST, "Paul E. McKenney"
><paulmck@kernel.org>
>> wrote:
>> >On Fri, Sep 04, 2026 at 06:28:45PM +0100, Bradley Morgan wrote:
>> >> On 4 September 2026 17:00:22 BST, "Paul E. McKenney"
>> ><paulmck@kernel.org>
>> >> wrote:
>> >> >On Fri, Sep 04, 2026 at 09:01:05AM -0400, Mathieu Desnoyers wrote:
>> >> >> On 2026-08-03 20:03, Bradley Morgan wrote:
>> >> >> > The do_pending kthread never sleeps. Its supposed to.
>> >> >> > kthread_do_pending_ms sets the gap between cleanups, and the
>docs
>> >> >> > say so too. But the sleep sits behind torture_must_stop(), and
>> >thats
>> >> >> > false while the test runs. So the kthread never sleeps. It just
>> >loops.
>> >> >> > It drains the pending lists over and over, no pause, and burns a
>> >full
>> >> >> > CPU for the whole test.
>> >> >> 
>> >> >> Paul, I just found this patch in my junk email folder. Maybe
>relevant
>> >> >> for you ?
>> >> >
>> >> >We got it in my -rcu tree:
>> >> >
>> >> >15b9fca2f5ce ("hazptrtorture: Fix inverted sleep condition in
>> >do_pending
>> >> >kthread")
>> >> >
>> >> >But I do appreciate your checking for missed patches, thank you!
>> >> >
>> >> >							Thanx, Paul
>> >> >
>> >> >> Thanks,
>> >> >> 
>> >> >> Mathieu
>> >> >> 
>> >> >> > 
>> >> >> > Flip the check. With !torture_must_stop() it sleeps for
>> >> >> > kthread_do_pending_ms between passes. When the test stops it
>does
>> >one
>> >> >> > last cleanup and exits. Nothing left to do, so no sleep needed
>> >then.
>> >> >> > 
>> >> >> > Fixes: 94d2e93c222e ("hazptrtorture: Add kthread to release
>> >deferred
>> >> >hazard pointers")
>> >> >> > Signed-off-by: Bradley Morgan <include@grrlz.net>
>> >> >> > ---
>> >> >> >   kernel/rcu/hazptrtorture.c | 2 +-
>> >> >> >   1 file changed, 1 insertion(+), 1 deletion(-)
>> >> >> > 
>> >> >> > diff --git a/kernel/rcu/hazptrtorture.c
>> >b/kernel/rcu/hazptrtorture.c
>> >> >> > index 72aeb50668e9..7c8b5899fb01 100644
>> >> >> > --- a/kernel/rcu/hazptrtorture.c
>> >> >> > +++ b/kernel/rcu/hazptrtorture.c
>> >> >> > @@ -555,7 +555,7 @@ static int hazptr_torture_do_pending(void
>*arg)
>> >> >> >   			cpu = cpumask_next_wrap(cpu, cpu_possible_mask);
>> >> >> >   			hazptr_torture_do_one_pending(cpu, &rand);
>> >> >> >   		}
>> >> >> > -		if (torture_must_stop())
>> >> >> > +		if (!torture_must_stop())
>> >> >> >   			torture_hrtimeout_ms(kthread_do_pending_ms, USEC_PER_MSEC, &rand);
>> >> >> >   		// Omit stutter_wait() because this function needs to do cleanup.
>> >> >> >   	} while (!torture_must_stop());
>> >> >> 
>> >> >> 
>> >> >> -- 
>> >> >> Mathieu Desnoyers
>> >> >> EfficiOS Inc.
>> >> >> https://www.efficios.com
>> >> >
>> >> >
>> >> Hi, new email.
>> >> 
>> >> Could I ask where the heck hazptr is? Its not in next, would you
>like,
>> >> help???
>> >> 
>> >> --- Thanks!
>> >>
>>
>>https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/
>> >
>> >It is still in my -rcu tree.
>> >
>> >I would not say "no" to a fix for this issue:
>> >
>>
>>https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/
>> >
>> >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.
>> 
>> Well, okay, tell me more and I'll develop it.
>
>I must confess that I have not looked much into that bug report, so I
>don't have much more to tell.

No, like the getting rid of wildcard hazptrs?

>
>						Thanx, Paul
>
>> --- Thanks!
>>
>https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/
>> 

--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

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

[Mathieu Desnoyers]

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@grrlz.net/

I'm not sure this URL actually points to a relevant issue ?

> 
> 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@efficios.com/

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

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

[Bradley Morgan]

On 6 September 2026 14:09:53 BST, Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> 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@grrlz.net/
>
>I'm not sure this URL actually points to a relevant issue ?
>

No, that URL is my signature, just in case people

1: add my old email to R-Bs, or SOBs.

2: makes people aware this is me.

>> 
>> 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@efficios.com/
>
>Thanks,
>
>Mathieu
>
>

--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

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

[Bradley Morgan]

On 6 September 2026 14:20:59 BST, Bradley Morgan <brads@mainlining.org>
wrote:
>On 6 September 2026 14:09:53 BST, Mathieu Desnoyers
><mathieu.desnoyers@efficios.com> 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@grrlz.net/
>>
>>I'm not sure this URL actually points to a relevant issue ?
>>
>
>No, that URL is my signature, just in case people
>
>1: add my old email to R-Bs, or SOBs.
>
>2: makes people aware this is me.
>
>>> 
>>> 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).
>>

Sure, I can help write it if you want

>>See:
>https://lore.kernel.org/all/20251218014531.3793471-1-mathieu.desnoyers@efficios.com/
>>
>>Thanks,
>>
>>Mathieu
>>
>>
>
>--- Thanks!
>https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

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

[Paul E. McKenney]

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@grrlz.net/
> 
> 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@intel.com/

> > 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@efficios.com/

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

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

[Bradley Morgan]

On 6 September 2026 19:46:50 BST, "Paul E. McKenney" <paulmck@kernel.org>
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@grrlz.net/
>> 
>> 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@intel.com/
>
>> > 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@efficios.com/
>
>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/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

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

[Paul E. McKenney]

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@kernel.org>
> 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@grrlz.net/
> >> 
> >> 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@intel.com/
> >
> >> > 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@efficios.com/
> >
> >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@grrlz.net/

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@kernel.org>
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@kernel.org>
>> 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@grrlz.net/
>> >> 
>> >> 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@intel.com/
>> >
>> >> > 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@efficios.com/
>> >
>> >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@grrlz.net/
Hey, test this fix?

From 3e92b8153c31106d6a080e1c9bbe9bf1e86e1f63 Mon Sep 17 00:00:00 2001
From: Bradley Morgan <brads@mainlining.org>
Date: Mon, 7 Sep 2026 18:00:08 +0000
Subject: [PATCH] hazptrtorture: Only detach acquired hazard pointers

hazptr_torture_acquire() detaches unconditionally, even when the
readlock fails. A failed acquire leaves nothing to detach, but the
detach still promotes the context to its backup slot and chains that
slot into the running CPU's overflow list. The reader then retries on
its own CPU, the fast path hands out a per-CPU slot and overwrites
ctx->slot, and the chained backup node is orphaned, still linked,
with nobody left to unchain it.

The next detach of the same context chains the same node a second
time, into another CPU's list, and the node ends up reachable from
both. The eventual release unchains it once, hlist_del() poisons
node->next, and the first list is left pointing at the poisoned node.
The writer's next hazptr_synchronize() walks that list, steps onto
LIST_POISON1 (0x100 on i386, where POISON_POINTER_DELTA is 0), and
reads slot.addr at offset 8 of the backup slot, address 0x108, which
is the crash the robot hit.

  cpuA (IPI acquire)     cpuR (reader)          cpuD (do_pending)
  ---------------------  ---------------------  -------------------
  readlock() returns
    NULL
  detach chains the
    backup node into
    cpuA list
                         hpp_htp is NULL,
                           continue
                         reacquire, ctx->slot
                           is now a cpuR
                           per-CPU slot
                         acquire succeeds,
                           defer, detach chains
                           the SAME node into
                           cpuR list
                                                release, unchain
                                                  once, node->next
                                                  is POISON1
                                                kfree(hppp)
  synchronize walks cpuA
    list, node->next is
    0x100, reads 0x108,
    Oops

Skip the detach when the acquire failed. The slot holds NULL in that
case, note_context_switch() and the synchronize scanners skip NULL
slots, and the next acquire overwrites ctx->slot, so leaving the
context attached is safe.

The robot's original report was against the defer path before detach
existed, which 4bd7f458229a fixed. This is the same crash surviving
through the IPI acquire path that 6357ec235c59 added.

Fixes: 6357ec235c59 ("hazptrtorture: Fix hazptr ownership issue")
Reported-by: kernel test robot <yi1.lai@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202608130915.62b53936-lkp@intel.com
Signed-off-by: Bradley Morgan <brads@mainlining.org>
---
 kernel/rcu/hazptrtorture.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/kernel/rcu/hazptrtorture.c b/kernel/rcu/hazptrtorture.c
index 7c8b589..267f262 100644
--- a/kernel/rcu/hazptrtorture.c
+++ b/kernel/rcu/hazptrtorture.c
@@ -373,8 +373,11 @@ static void hazptr_torture_acquire(void *hppp_in)
 	/*
 	 * Acquiring a hazard pointer from a remote CPU.
 	 * Detach hazptr from its task so it can be released by another task.
+	 * A failed acquire has nothing to detach, and detaching one anyway
+	 * orphans the chained backup slot on this CPU's overflow list.
 	 */
-	hazptr_detach(&hppp->hpp_hc);
+	if (hppp->hpp_htp)
+		hazptr_detach(&hppp->hpp_hc);
 	atomic_long_inc(per_cpu_ptr(&hazptr_torture_acquires_irq, raw_smp_processor_id()));
 }
 
-- 
2.47.3


--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

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

[Paul E. McKenney]

On Mon, Sep 07, 2026 at 07:11:53PM +0100, Bradley Morgan wrote:
> On 7 September 2026 00:16:55 BST, "Paul E. McKenney" <paulmck@kernel.org>
> 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@kernel.org>
> >> 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@grrlz.net/
> >> >> 
> >> >> 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@intel.com/
> >> >
> >> >> > 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@efficios.com/
> >> >
> >> >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@grrlz.net/
> Hey, test this fix?

Very good, thank you!

Please post this patch as a reply to the report, asking them to test:

https://lore.kernel.org/all/202608130915.62b53936-lkp@intel.com/

But first, have you tested it locally?  Something like this:

tools/testing/selftests/rcutorture/bin/kvm.sh --torture hazptr --allcpus --duration 2h

Would run a two-hour test of each of the two scenarios, within a guest OS.
If your host system has 32 or more CPUs, it will run both scenarios
concurrently.

							Thanx, Paul

> >From 3e92b8153c31106d6a080e1c9bbe9bf1e86e1f63 Mon Sep 17 00:00:00 2001
> From: Bradley Morgan <brads@mainlining.org>
> Date: Mon, 7 Sep 2026 18:00:08 +0000
> Subject: [PATCH] hazptrtorture: Only detach acquired hazard pointers
> 
> hazptr_torture_acquire() detaches unconditionally, even when the
> readlock fails. A failed acquire leaves nothing to detach, but the
> detach still promotes the context to its backup slot and chains that
> slot into the running CPU's overflow list. The reader then retries on
> its own CPU, the fast path hands out a per-CPU slot and overwrites
> ctx->slot, and the chained backup node is orphaned, still linked,
> with nobody left to unchain it.
> 
> The next detach of the same context chains the same node a second
> time, into another CPU's list, and the node ends up reachable from
> both. The eventual release unchains it once, hlist_del() poisons
> node->next, and the first list is left pointing at the poisoned node.
> The writer's next hazptr_synchronize() walks that list, steps onto
> LIST_POISON1 (0x100 on i386, where POISON_POINTER_DELTA is 0), and
> reads slot.addr at offset 8 of the backup slot, address 0x108, which
> is the crash the robot hit.
> 
>   cpuA (IPI acquire)     cpuR (reader)          cpuD (do_pending)
>   ---------------------  ---------------------  -------------------
>   readlock() returns
>     NULL
>   detach chains the
>     backup node into
>     cpuA list
>                          hpp_htp is NULL,
>                            continue
>                          reacquire, ctx->slot
>                            is now a cpuR
>                            per-CPU slot
>                          acquire succeeds,
>                            defer, detach chains
>                            the SAME node into
>                            cpuR list
>                                                 release, unchain
>                                                   once, node->next
>                                                   is POISON1
>                                                 kfree(hppp)
>   synchronize walks cpuA
>     list, node->next is
>     0x100, reads 0x108,
>     Oops
> 
> Skip the detach when the acquire failed. The slot holds NULL in that
> case, note_context_switch() and the synchronize scanners skip NULL
> slots, and the next acquire overwrites ctx->slot, so leaving the
> context attached is safe.
> 
> The robot's original report was against the defer path before detach
> existed, which 4bd7f458229a fixed. This is the same crash surviving
> through the IPI acquire path that 6357ec235c59 added.
> 
> Fixes: 6357ec235c59 ("hazptrtorture: Fix hazptr ownership issue")
> Reported-by: kernel test robot <yi1.lai@intel.com>
> Closes: https://lore.kernel.org/oe-lkp/202608130915.62b53936-lkp@intel.com
> Signed-off-by: Bradley Morgan <brads@mainlining.org>
> ---
>  kernel/rcu/hazptrtorture.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/rcu/hazptrtorture.c b/kernel/rcu/hazptrtorture.c
> index 7c8b589..267f262 100644
> --- a/kernel/rcu/hazptrtorture.c
> +++ b/kernel/rcu/hazptrtorture.c
> @@ -373,8 +373,11 @@ static void hazptr_torture_acquire(void *hppp_in)
>  	/*
>  	 * Acquiring a hazard pointer from a remote CPU.
>  	 * Detach hazptr from its task so it can be released by another task.
> +	 * A failed acquire has nothing to detach, and detaching one anyway
> +	 * orphans the chained backup slot on this CPU's overflow list.
>  	 */
> -	hazptr_detach(&hppp->hpp_hc);
> +	if (hppp->hpp_htp)
> +		hazptr_detach(&hppp->hpp_hc);
>  	atomic_long_inc(per_cpu_ptr(&hazptr_torture_acquires_irq, raw_smp_processor_id()));
>  }
>  
> -- 
> 2.47.3
> 
> 
> --- Thanks!
> https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

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

[Bradley Morgan]

On 7 September 2026 21:18:50 BST, "Paul E. McKenney" <paulmck@kernel.org>
wrote:
>On Mon, Sep 07, 2026 at 07:11:53PM +0100, Bradley Morgan wrote:
>> On 7 September 2026 00:16:55 BST, "Paul E. McKenney"
><paulmck@kernel.org>
>> 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@kernel.org>
>> >> 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@grrlz.net/
>> >> >> 
>> >> >> 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@intel.com/
>> >> >
>> >> >> > 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@efficios.com/
>> >> >
>> >> >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@grrlz.net/
>> Hey, test this fix?
>
>Very good, thank you!
>
>Please post this patch as a reply to the report, asking them to test:
>
>https://lore.kernel.org/all/202608130915.62b53936-lkp@intel.com/
>
>But first, have you tested it locally?  Something like this:
>
>tools/testing/selftests/rcutorture/bin/kvm.sh --torture hazptr --allcpus
>--duration 2h
>
>Would run a two-hour test of each of the two scenarios, within a guest OS.
>If your host system has 32 or more CPUs, it will run both scenarios
>concurrently.
>
>							Thanx, Paul

My server is pathetic, it's terrible, it takes a while to build a full
kernel, in, (gulp) 4 gb of ram (oh no!) but I leave it sitting when doing
full kernel builds, a torture test would kill it. Hah.

I'll post the patch soon.


>
>> >From 3e92b8153c31106d6a080e1c9bbe9bf1e86e1f63 Mon Sep 17 00:00:00 2001
>> From: Bradley Morgan <brads@mainlining.org>
>> Date: Mon, 7 Sep 2026 18:00:08 +0000
>> Subject: [PATCH] hazptrtorture: Only detach acquired hazard pointers
>> 
>> hazptr_torture_acquire() detaches unconditionally, even when the
>> readlock fails. A failed acquire leaves nothing to detach, but the
>> detach still promotes the context to its backup slot and chains that
>> slot into the running CPU's overflow list. The reader then retries on
>> its own CPU, the fast path hands out a per-CPU slot and overwrites
>> ctx->slot, and the chained backup node is orphaned, still linked,
>> with nobody left to unchain it.
>> 
>> The next detach of the same context chains the same node a second
>> time, into another CPU's list, and the node ends up reachable from
>> both. The eventual release unchains it once, hlist_del() poisons
>> node->next, and the first list is left pointing at the poisoned node.
>> The writer's next hazptr_synchronize() walks that list, steps onto
>> LIST_POISON1 (0x100 on i386, where POISON_POINTER_DELTA is 0), and
>> reads slot.addr at offset 8 of the backup slot, address 0x108, which
>> is the crash the robot hit.
>> 
>>   cpuA (IPI acquire)     cpuR (reader)          cpuD (do_pending)
>>   ---------------------  ---------------------  -------------------
>>   readlock() returns
>>     NULL
>>   detach chains the
>>     backup node into
>>     cpuA list
>>                          hpp_htp is NULL,
>>                            continue
>>                          reacquire, ctx->slot
>>                            is now a cpuR
>>                            per-CPU slot
>>                          acquire succeeds,
>>                            defer, detach chains
>>                            the SAME node into
>>                            cpuR list
>>                                                 release, unchain
>>                                                   once, node->next
>>                                                   is POISON1
>>                                                 kfree(hppp)
>>   synchronize walks cpuA
>>     list, node->next is
>>     0x100, reads 0x108,
>>     Oops
>> 
>> Skip the detach when the acquire failed. The slot holds NULL in that
>> case, note_context_switch() and the synchronize scanners skip NULL
>> slots, and the next acquire overwrites ctx->slot, so leaving the
>> context attached is safe.
>> 
>> The robot's original report was against the defer path before detach
>> existed, which 4bd7f458229a fixed. This is the same crash surviving
>> through the IPI acquire path that 6357ec235c59 added.
>> 
>> Fixes: 6357ec235c59 ("hazptrtorture: Fix hazptr ownership issue")
>> Reported-by: kernel test robot <yi1.lai@intel.com>
>> Closes:
>https://lore.kernel.org/oe-lkp/202608130915.62b53936-lkp@intel.com
>> Signed-off-by: Bradley Morgan <brads@mainlining.org>
>> ---
>>  kernel/rcu/hazptrtorture.c | 5 ++++-
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>> 
>> diff --git a/kernel/rcu/hazptrtorture.c b/kernel/rcu/hazptrtorture.c
>> index 7c8b589..267f262 100644
>> --- a/kernel/rcu/hazptrtorture.c
>> +++ b/kernel/rcu/hazptrtorture.c
>> @@ -373,8 +373,11 @@ static void hazptr_torture_acquire(void *hppp_in)
>>  	/*
>>  	 * Acquiring a hazard pointer from a remote CPU.
>>  	 * Detach hazptr from its task so it can be released by another task.
>> +	 * A failed acquire has nothing to detach, and detaching one anyway
>> +	 * orphans the chained backup slot on this CPU's overflow list.
>>  	 */
>> -	hazptr_detach(&hppp->hpp_hc);
>> +	if (hppp->hpp_htp)
>> +		hazptr_detach(&hppp->hpp_hc);
>>  	atomic_long_inc(per_cpu_ptr(&hazptr_torture_acquires_irq, raw_smp_processor_id()));
>>  }
>>  
>> -- 
>> 2.47.3
>> 
>> 
>> --- Thanks!
>>
>https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/