Re: [PATCH] locking/locktorture: reject zero resolved worker threads
From: Samuel Moelius
Date: Sun Jun 07 2026 - 10:26:37 EST
On Fri, Jun 5, 2026 at 10:46 PM Paul E. McKenney <paulmck@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx>
> > ---
> > 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?