[PATCH] locking/locktorture: reject zero resolved worker threads

[PATCH] locking/locktorture: reject zero resolved worker threads

[Samuel Moelius]

locktorture checks for a zero-worker configuration before it resolves
the default reader count.  For reader-capable lock types, a user can
pass nwriters_stress=0 and leave nreaders_stress at its default -1.
This bypasses the early check, then derives the default real reader
count from the real writer count, leaving both resolved counts at zero.

The module can then load successfully, optionally creating helper
threads such as the stats thread, but no lock-torture worker threads.

Reject the resolved zero-worker state after reader defaults have been
applied.

Assisted-by: Codex:gpt-5.5-cyber-preview
Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com>
---
 kernel/locking/locktorture.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
index e618bcf75e2d..7d553ecd3fab 100644
--- a/kernel/locking/locktorture.c
+++ b/kernel/locking/locktorture.c
@@ -1320,6 +1320,13 @@ static int __init lock_torture_init(void)
 			cxt.nrealreaders_stress = cxt.nrealwriters_stress;
 		}
 
+		if (cxt.nrealwriters_stress == 0 &&
+		    cxt.nrealreaders_stress == 0) {
+			pr_alert("lock-torture: must run at least one locking thread\n");
+			firsterr = -EINVAL;
+			goto unwind;
+		}
+
 		if (nreaders_stress) {
 			cxt.lrsa = kmalloc_objs(*cxt.lrsa,
 						cxt.nrealreaders_stress);
-- 
2.43.0

Re: [PATCH] locking/locktorture: reject zero resolved worker threads

[Paul E. McKenney]

On Fri, Jun 05, 2026 at 06:47:05PM +0000, Samuel Moelius wrote:
> locktorture checks for a zero-worker configuration before it resolves
> the default reader count.  For reader-capable lock types, a user can
> pass nwriters_stress=0 and leave nreaders_stress at its default -1.
> This bypasses the early check, then derives the default real reader
> count from the real writer count, leaving both resolved counts at zero.
> 
> The module can then load successfully, optionally creating helper
> threads such as the stats thread, but no lock-torture worker threads.
> 
> Reject the resolved zero-worker state after reader defaults have been
> applied.
> 
> Assisted-by: Codex:gpt-5.5-cyber-preview
> Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com>
> ---
>  kernel/locking/locktorture.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
> index e618bcf75e2d..7d553ecd3fab 100644
> --- a/kernel/locking/locktorture.c
> +++ b/kernel/locking/locktorture.c
> @@ -1320,6 +1320,13 @@ static int __init lock_torture_init(void)
>  			cxt.nrealreaders_stress = cxt.nrealwriters_stress;
>  		}
>  
> +		if (cxt.nrealwriters_stress == 0 &&
> +		    cxt.nrealreaders_stress == 0) {
> +			pr_alert("lock-torture: must run at least one locking thread\n");
> +			firsterr = -EINVAL;
> +			goto unwind;
> +		}
> +
>  		if (nreaders_stress) {
>  			cxt.lrsa = kmalloc_objs(*cxt.lrsa,
>  						cxt.nrealreaders_stress);

Fair point!

Though if we are to fully handle erroneous combinations of module
parameters to this debug module, there is also later code that updates
cxt.nrealwriters_stress *after* having allocated and initialized the
cxt.lwsa array.  And likely other issues.

Would you be willing to review lock_torture_init() to fix all aspects of
its error handling?  If we do it one at a time, we will after all likely
go in circles for some time.  And that won't be fun for any of us.  ;-)

							Thanx, Paul

Re: [PATCH] locking/locktorture: reject zero resolved worker threads

[Samuel Moelius]

On Fri, Jun 5, 2026 at 10:46 PM Paul E. McKenney <paulmck@kernel.org> wrote:
>
> On Fri, Jun 05, 2026 at 06:47:05PM +0000, Samuel Moelius wrote:
> > locktorture checks for a zero-worker configuration before it resolves
> > the default reader count.  For reader-capable lock types, a user can
> > pass nwriters_stress=0 and leave nreaders_stress at its default -1.
> > This bypasses the early check, then derives the default real reader
> > count from the real writer count, leaving both resolved counts at zero.
> >
> > The module can then load successfully, optionally creating helper
> > threads such as the stats thread, but no lock-torture worker threads.
> >
> > Reject the resolved zero-worker state after reader defaults have been
> > applied.
> >
> > Assisted-by: Codex:gpt-5.5-cyber-preview
> > Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com>
> > ---
> >  kernel/locking/locktorture.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
> > index e618bcf75e2d..7d553ecd3fab 100644
> > --- a/kernel/locking/locktorture.c
> > +++ b/kernel/locking/locktorture.c
> > @@ -1320,6 +1320,13 @@ static int __init lock_torture_init(void)
> >                       cxt.nrealreaders_stress = cxt.nrealwriters_stress;
> >               }
> >
> > +             if (cxt.nrealwriters_stress == 0 &&
> > +                 cxt.nrealreaders_stress == 0) {
> > +                     pr_alert("lock-torture: must run at least one locking thread\n");
> > +                     firsterr = -EINVAL;
> > +                     goto unwind;
> > +             }
> > +
> >               if (nreaders_stress) {
> >                       cxt.lrsa = kmalloc_objs(*cxt.lrsa,
> >                                               cxt.nrealreaders_stress);
>
> Fair point!
>
> Though if we are to fully handle erroneous combinations of module
> parameters to this debug module, there is also later code that updates
> cxt.nrealwriters_stress *after* having allocated and initialized the
> cxt.lwsa array.  And likely other issues.
>
> Would you be willing to review lock_torture_init() to fix all aspects of
> its error handling?  If we do it one at a time, we will after all likely
> go in circles for some time.  And that won't be fun for any of us.  ;-)

Your point is well taken regarding this being a debug module. But I
have limited access to the gpt-5.5-cyber model, and my goal is to find
as many bugs with it in the time that I have. Could I respectfully
request that this patch be considered in isolation?

Re: [PATCH] locking/locktorture: reject zero resolved worker threads

[Paul E. McKenney]

On Sun, Jun 07, 2026 at 10:26:03AM -0400, Samuel Moelius wrote:
> On Fri, Jun 5, 2026 at 10:46 PM Paul E. McKenney <paulmck@kernel.org> wrote:
> >
> > On Fri, Jun 05, 2026 at 06:47:05PM +0000, Samuel Moelius wrote:
> > > locktorture checks for a zero-worker configuration before it resolves
> > > the default reader count.  For reader-capable lock types, a user can
> > > pass nwriters_stress=0 and leave nreaders_stress at its default -1.
> > > This bypasses the early check, then derives the default real reader
> > > count from the real writer count, leaving both resolved counts at zero.
> > >
> > > The module can then load successfully, optionally creating helper
> > > threads such as the stats thread, but no lock-torture worker threads.
> > >
> > > Reject the resolved zero-worker state after reader defaults have been
> > > applied.
> > >
> > > Assisted-by: Codex:gpt-5.5-cyber-preview
> > > Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com>
> > > ---
> > >  kernel/locking/locktorture.c | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
> > > index e618bcf75e2d..7d553ecd3fab 100644
> > > --- a/kernel/locking/locktorture.c
> > > +++ b/kernel/locking/locktorture.c
> > > @@ -1320,6 +1320,13 @@ static int __init lock_torture_init(void)
> > >                       cxt.nrealreaders_stress = cxt.nrealwriters_stress;
> > >               }
> > >
> > > +             if (cxt.nrealwriters_stress == 0 &&
> > > +                 cxt.nrealreaders_stress == 0) {
> > > +                     pr_alert("lock-torture: must run at least one locking thread\n");
> > > +                     firsterr = -EINVAL;
> > > +                     goto unwind;
> > > +             }
> > > +
> > >               if (nreaders_stress) {
> > >                       cxt.lrsa = kmalloc_objs(*cxt.lrsa,
> > >                                               cxt.nrealreaders_stress);
> >
> > Fair point!
> >
> > Though if we are to fully handle erroneous combinations of module
> > parameters to this debug module, there is also later code that updates
> > cxt.nrealwriters_stress *after* having allocated and initialized the
> > cxt.lwsa array.  And likely other issues.
> >
> > Would you be willing to review lock_torture_init() to fix all aspects of
> > its error handling?  If we do it one at a time, we will after all likely
> > go in circles for some time.  And that won't be fun for any of us.  ;-)
> 
> Your point is well taken regarding this being a debug module. But I
> have limited access to the gpt-5.5-cyber model, and my goal is to find
> as many bugs with it in the time that I have. Could I respectfully
> request that this patch be considered in isolation?

If I get time to bring this module's error checking out of expert-only
mode, I will of course give you a Reported-by.

							Thanx, Paul