[PATCH] rcutorture: Fix suspicious rcu_dereference_check() usage for trivial-preempt

[PATCH] rcutorture: Fix suspicious rcu_dereference_check() usage for trivial-preempt

[Zqiang]

Running the trivial-preempt flavor triggers a lockdep "suspicious RCU
usage" warning from rcu_torture_one_read_start():

WARNING: suspicious RCU usage
kernel/rcu/rcutorture.c:2581 suspicious rcu_dereference_check() usage!
...
lockdep_rcu_suspicious
rcu_torture_one_read_start
rcu_torture_one_read
rcu_torture_reader

The trivial-preempt flavor .readlock_held is set to torture_readlock_not_held(),
which check RCU-bh/RCU-sched critical sections. however, it's read lock
just increments current->rcu_trivial_preempt_nesting, it's not also RCU
read critical sections. the rcu_dereference_check() condition is therefore
false, and lockdep report warnings. this commit therefore drop .readlock_held
callback to avoid this lockdep warnings.

Fixes: c6f4e552e1ea ("rcutorture: Add a textbook-style trivial preemptible RCU")
Signed-off-by: Zqiang <qiang.zhang@linux.dev>
---
 kernel/rcu/rcutorture.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 92ff197f4789..1bbf8192786a 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -1164,7 +1164,6 @@ static struct rcu_torture_ops trivial_preempt_ops = {
 	.readlock	= rcu_torture_read_lock_trivial_preempt,
 	.read_delay	= rcu_read_delay,  // just reuse rcu's version.
 	.readunlock	= rcu_torture_read_unlock_trivial_preempt,
-	.readlock_held	= torture_readlock_not_held,
 	.get_gp_seq	= rcu_no_completed,
 	.sync		= synchronize_rcu_trivial_preempt,
 	.exp_sync	= synchronize_rcu_trivial_preempt,
-- 
2.17.1

Re: [PATCH] rcutorture: Fix suspicious rcu_dereference_check() usage for trivial-preempt

[Bradley Morgan]

On 20 October 2026 10:49:07 BST, Zqiang <qiang.zhang@linux.dev> wrote:
>Running the trivial-preempt flavor triggers a lockdep "suspicious RCU
>usage" warning from rcu_torture_one_read_start():
>
>WARNING: suspicious RCU usage
>kernel/rcu/rcutorture.c:2581 suspicious rcu_dereference_check() usage!
>...
>lockdep_rcu_suspicious
>rcu_torture_one_read_start
>rcu_torture_one_read
>rcu_torture_reader
>
>The trivial-preempt flavor .readlock_held is set to
>torture_readlock_not_held(),
>which check RCU-bh/RCU-sched critical sections. however, it's read lock
>just increments current->rcu_trivial_preempt_nesting, it's not also RCU
>read critical sections. the rcu_dereference_check() condition is therefore
>false, and lockdep report warnings. this commit therefore drop
>.readlock_held
>callback to avoid this lockdep warnings.
>
>Fixes: c6f4e552e1ea ("rcutorture: Add a textbook-style trivial preemptible RCU")

Looks ok to me.

Reviewed-by: Bradley Morgan <brads@mainlining.org>


>Signed-off-by: Zqiang <qiang.zhang@linux.dev>
>---
> kernel/rcu/rcutorture.c | 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
>index 92ff197f4789..1bbf8192786a 100644
>--- a/kernel/rcu/rcutorture.c
>+++ b/kernel/rcu/rcutorture.c
>@@ -1164,7 +1164,6 @@ static struct rcu_torture_ops trivial_preempt_ops = {
> 	.readlock	= rcu_torture_read_lock_trivial_preempt,
> 	.read_delay	= rcu_read_delay,  // just reuse rcu's version.
> 	.readunlock	= rcu_torture_read_unlock_trivial_preempt,
>-	.readlock_held	= torture_readlock_not_held,
> 	.get_gp_seq	= rcu_no_completed,
> 	.sync		= synchronize_rcu_trivial_preempt,
> 	.exp_sync	= synchronize_rcu_trivial_preempt,
>

--- Thanks!
"I'm not a very positive person" - Linus torvalds

Re: [PATCH] rcutorture: Fix suspicious rcu_dereference_check() usage for trivial-preempt

[Paul E. McKenney]

On Tue, Oct 20, 2026 at 04:06:49PM +0100, Bradley Morgan wrote:
> On 20 October 2026 10:49:07 BST, Zqiang <qiang.zhang@linux.dev> wrote:
> >Running the trivial-preempt flavor triggers a lockdep "suspicious RCU
> >usage" warning from rcu_torture_one_read_start():
> >
> >WARNING: suspicious RCU usage
> >kernel/rcu/rcutorture.c:2581 suspicious rcu_dereference_check() usage!
> >...
> >lockdep_rcu_suspicious
> >rcu_torture_one_read_start
> >rcu_torture_one_read
> >rcu_torture_reader
> >
> >The trivial-preempt flavor .readlock_held is set to
> >torture_readlock_not_held(),
> >which check RCU-bh/RCU-sched critical sections. however, it's read lock
> >just increments current->rcu_trivial_preempt_nesting, it's not also RCU
> >read critical sections. the rcu_dereference_check() condition is therefore
> >false, and lockdep report warnings. this commit therefore drop
> >.readlock_held
> >callback to avoid this lockdep warnings.
> >
> >Fixes: c6f4e552e1ea ("rcutorture: Add a textbook-style trivial preemptible RCU")
> 
> Looks ok to me.
> 
> Reviewed-by: Bradley Morgan <brads@mainlining.org>
> 
> >Signed-off-by: Zqiang <qiang.zhang@linux.dev>

And it works here, thank you both.  I have queued this, and thank you
Zqiang for thinking to test trivial-preempt with lockdep enabled!

							Thanx, Paul

> >---
> > kernel/rcu/rcutorture.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> >diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> >index 92ff197f4789..1bbf8192786a 100644
> >--- a/kernel/rcu/rcutorture.c
> >+++ b/kernel/rcu/rcutorture.c
> >@@ -1164,7 +1164,6 @@ static struct rcu_torture_ops trivial_preempt_ops = {
> > 	.readlock	= rcu_torture_read_lock_trivial_preempt,
> > 	.read_delay	= rcu_read_delay,  // just reuse rcu's version.
> > 	.readunlock	= rcu_torture_read_unlock_trivial_preempt,
> >-	.readlock_held	= torture_readlock_not_held,
> > 	.get_gp_seq	= rcu_no_completed,
> > 	.sync		= synchronize_rcu_trivial_preempt,
> > 	.exp_sync	= synchronize_rcu_trivial_preempt,
> >
> 
> --- Thanks!
> "I'm not a very positive person" - Linus torvalds

Re: [PATCH] rcutorture: Fix suspicious rcu_dereference_check() usage for trivial-preempt

[Paul E. McKenney]

On Tue, Oct 20, 2026 at 03:01:27PM -0700, Paul E. McKenney wrote:
> On Tue, Oct 20, 2026 at 04:06:49PM +0100, Bradley Morgan wrote:
> > On 20 October 2026 10:49:07 BST, Zqiang <qiang.zhang@linux.dev> wrote:
> > >Running the trivial-preempt flavor triggers a lockdep "suspicious RCU
> > >usage" warning from rcu_torture_one_read_start():
> > >
> > >WARNING: suspicious RCU usage
> > >kernel/rcu/rcutorture.c:2581 suspicious rcu_dereference_check() usage!
> > >...
> > >lockdep_rcu_suspicious
> > >rcu_torture_one_read_start
> > >rcu_torture_one_read
> > >rcu_torture_reader
> > >
> > >The trivial-preempt flavor .readlock_held is set to
> > >torture_readlock_not_held(),
> > >which check RCU-bh/RCU-sched critical sections. however, it's read lock
> > >just increments current->rcu_trivial_preempt_nesting, it's not also RCU
> > >read critical sections. the rcu_dereference_check() condition is therefore
> > >false, and lockdep report warnings. this commit therefore drop
> > >.readlock_held
> > >callback to avoid this lockdep warnings.
> > >
> > >Fixes: c6f4e552e1ea ("rcutorture: Add a textbook-style trivial preemptible RCU")
> > 
> > Looks ok to me.
> > 
> > Reviewed-by: Bradley Morgan <brads@mainlining.org>
> > 
> > >Signed-off-by: Zqiang <qiang.zhang@linux.dev>
> 
> And it works here, thank you both.  I have queued this, and thank you
> Zqiang for thinking to test trivial-preempt with lockdep enabled!

Wait, Joel is doing the next merge window, not me!

Joel, please make that be:

Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
Tested-by: Paul E. McKenney <paulmck@kernel.org>

I will drop it from my tree, apologies for my confusion!

							Thanx, Paul

> > >---
> > > kernel/rcu/rcutorture.c | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > >diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> > >index 92ff197f4789..1bbf8192786a 100644
> > >--- a/kernel/rcu/rcutorture.c
> > >+++ b/kernel/rcu/rcutorture.c
> > >@@ -1164,7 +1164,6 @@ static struct rcu_torture_ops trivial_preempt_ops = {
> > > 	.readlock	= rcu_torture_read_lock_trivial_preempt,
> > > 	.read_delay	= rcu_read_delay,  // just reuse rcu's version.
> > > 	.readunlock	= rcu_torture_read_unlock_trivial_preempt,
> > >-	.readlock_held	= torture_readlock_not_held,
> > > 	.get_gp_seq	= rcu_no_completed,
> > > 	.sync		= synchronize_rcu_trivial_preempt,
> > > 	.exp_sync	= synchronize_rcu_trivial_preempt,
> > >
> > 
> > --- Thanks!
> > "I'm not a very positive person" - Linus torvalds

Re: [PATCH] rcutorture: Fix suspicious rcu_dereference_check() usage for trivial-preempt

[Joel Fernandes]

On Tue, Oct 20, 2026 at 03:03:27PM -0700, Paul E. McKenney wrote:
> On Tue, Oct 20, 2026 at 03:01:27PM -0700, Paul E. McKenney wrote:
> > On Tue, Oct 20, 2026 at 04:06:49PM +0100, Bradley Morgan wrote:
> > > On 20 October 2026 10:49:07 BST, Zqiang <qiang.zhang@linux.dev> wrote:
> > > >Running the trivial-preempt flavor triggers a lockdep "suspicious RCU
> > > >usage" warning from rcu_torture_one_read_start():
> > > >
> > > >WARNING: suspicious RCU usage
> > > >kernel/rcu/rcutorture.c:2581 suspicious rcu_dereference_check() usage!
> > > >...
> > > >lockdep_rcu_suspicious
> > > >rcu_torture_one_read_start
> > > >rcu_torture_one_read
> > > >rcu_torture_reader
> > > >
> > > >The trivial-preempt flavor .readlock_held is set to
> > > >torture_readlock_not_held(),
> > > >which check RCU-bh/RCU-sched critical sections. however, it's read lock
> > > >just increments current->rcu_trivial_preempt_nesting, it's not also RCU
> > > >read critical sections. the rcu_dereference_check() condition is therefore
> > > >false, and lockdep report warnings. this commit therefore drop
> > > >.readlock_held
> > > >callback to avoid this lockdep warnings.
> > > >
> > > >Fixes: c6f4e552e1ea ("rcutorture: Add a textbook-style trivial preemptible RCU")
> > > 
> > > Looks ok to me.
> > > 
> > > Reviewed-by: Bradley Morgan <brads@mainlining.org>
> > > 
> > > >Signed-off-by: Zqiang <qiang.zhang@linux.dev>
> > 
> > And it works here, thank you both.  I have queued this, and thank you
> > Zqiang for thinking to test trivial-preempt with lockdep enabled!
> 
> Wait, Joel is doing the next merge window, not me!
> 
> Joel, please make that be:
> 
> Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> Tested-by: Paul E. McKenney <paulmck@kernel.org>
> 
> I will drop it from my tree, apologies for my confusion!

Applied for 7.5 for further testing, thanks!

thanks,

Joel Fernandes