linux-kernel - Re: [PATCH v4] rcutorture: Create nocb tasks only for rcu testing and CONFIG_RCU_NOCB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20230203175123.GK2948950@paulmck-ThinkPad-P17-Gen-1>
Date:   Fri, 3 Feb 2023 09:51:23 -0800
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Joel Fernandes <joel@...lfernandes.org>
Cc:     Zqiang <qiang1.zhang@...el.com>, frederic@...nel.org,
        quic_neeraju@...cinc.com, rcu@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] rcutorture: Create nocb tasks only for rcu testing
 and CONFIG_RCU_NOCB_CPU=y kernel

On Fri, Feb 03, 2023 at 12:29:23PM -0500, Joel Fernandes wrote:
> On Fri, Feb 3, 2023 at 1:35 AM Zqiang <qiang1.zhang@...el.com> wrote:
> >
> > When setting nocbs_nthreads to start rcutorture test with a non-zero value,
> > the nocb tasks will be created and invoke rcu_nocb_cpu_offload/deoffload()
> > to toggle CPU's callback-offload state, but this is meaningless for non-rcu
> > testing or CONFIG_RCU_NOCB_CPU=n kernel create nocb tasks to periodically
> > toggle CPU's callback-offload state and adds unnecessary testing overhead.
> >
> > This commit therefore add checks for cur_ops types and CONFIG_RCU_NOCB_CPU
> > options when nocbs_nthreads is non-zero to avoid unnecessary nocb task
> > creation.
> >
> > Signed-off-by: Zqiang <qiang1.zhang@...el.com>
> 
> Reviewed-by: Joel Fernandes (Google) <joel@...lfernandes.org>

Queued and pushed, thank you both!

Note that this loses testing of the offload/de-offload API when there
is nothing to offload or de-offload, but that is not necessarily the job
of rcutorture.  Or if it is the job of rcutorture, perhaps it is a single
pair of calls somewhere.  And that can certainly be a separate patch.

But perhaps Frederic has an opinion on what testing is needed for this
case, and if so where that testing should live.

							Thanx, Paul

> thanks,
> 
>  - Joel
> 
> 
> > ---
> >  kernel/rcu/rcutorture.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> > index 297da28ce92d..d01127e0e8cd 100644
> > --- a/kernel/rcu/rcutorture.c
> > +++ b/kernel/rcu/rcutorture.c
> > @@ -3708,6 +3708,12 @@ rcu_torture_init(void)
> >                 pr_alert("rcu-torture: ->fqs NULL and non-zero fqs_duration, fqs disabled.\n");
> >                 fqs_duration = 0;
> >         }
> > +       if (nocbs_nthreads != 0 && (cur_ops != &rcu_ops ||
> > +                                       !IS_ENABLED(CONFIG_RCU_NOCB_CPU))) {
> > +               pr_alert("rcu-torture types: %s and CONFIG_RCU_NOCB_CPU=%d, nocb toggle disabled.\n",
> > +                               cur_ops->name, IS_ENABLED(CONFIG_RCU_NOCB_CPU));
> > +               nocbs_nthreads = 0;
> > +       }
> >         if (cur_ops->init)
> >                 cur_ops->init();
> >
> > --
> > 2.25.1
> >