Received-SPF: pass (google.com: domain of linux-kernel+bounces-198606-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <20240528030054.4525-1-qiang.zhang1211@gmail.com>
 <1195a9a3-db87-465d-a3b0-ee92d67da954@paulmck-laptop> <CALm+0cVZ7GQC+v4Xe7nArh0DHKeax+ok_tYsKaB=JtG-BVgUag@mail.gmail.com>
In-Reply-To: <CALm+0cVZ7GQC+v4Xe7nArh0DHKeax+ok_tYsKaB=JtG-BVgUag@mail.gmail.com>
From: Z qiang <qiang.zhang1211@gmail.com>
Date: Mon, 3 Jun 2024 12:55:30 +0800
Message-ID: <CALm+0cUQuZDb6nrng+CnOXNGyy6gUWNGq9VoreU98KNkyTw_CQ@mail.gmail.com>
Subject: Re: [PATCH] rcutorture: Skip debug object testing for cur_ops without
 ->debug_objects set
To: paulmck@kernel.org
Cc: frederic@kernel.org, neeraj.upadhyay@kernel.org, joel@joelfernandes.org, 
	urezki@gmail.com, rcu@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"

>
> >
> > On Tue, May 28, 2024 at 11:00:54AM +0800, Zqiang wrote:
> > > This commit make rcu_test_debug_objects() early return when the
> > > specified cur_ops not set the ->debug_objects.
> > >
> > > Signed-off-by: Zqiang <qiang.zhang1211@gmail.com>
> > > ---
> > >  kernel/rcu/rcutorture.c | 5 +++--
> > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> > > index 08bf7c669dd3..9b8c277ab91a 100644
> > > --- a/kernel/rcu/rcutorture.c
> > > +++ b/kernel/rcu/rcutorture.c
> > > @@ -3495,8 +3495,9 @@ static void rcu_test_debug_objects(void)
> > >               return;
> > >       }
> > >
> > > -     if (WARN_ON_ONCE(cur_ops->debug_objects &&
> > > -                     (!cur_ops->call || !cur_ops->cb_barrier)))
> > > +     if (!cur_ops->debug_objects ||
> > > +                     WARN_ON_ONCE(cur_ops->debug_objects &&
> >
> > You lost me here.  Given that we have "!cur_ops->debug_objects" before
> > that WARN_ON_ONCE(), why do we need "cur_ops->debug_objects" inside of it?
> >
> > Also, we don't get here unless the rcutorture.object_debug kernel boot
> > parameter is specified, don't we really want to WARN_ON_ONCE if the
> > current flavor does not support that?

Maybe I didn't describe it clearly enough, this
modification is mainly to filter out test types that do not support
double call_rcu*() checking, for example tasks, tasks-rudes,
 task-tracing  ;) .

Thanks
Zqiang

>
> Hi, Paul
>
> The rcutorture.object_debug is set true, but the tasks-tracing does not support
> duplicate cur_ops->call check, but the debug_objects test was still done.
>
> insmod rcutorture.ko torture_type=tasks-tracing fwd_progress=4
> n_barrier_cbs=4 object_debug=1
>
> [  106.082416] rcutorture: WARN: Duplicate call_tasks-tracing() test starting.
> [  106.082533] tasks-tracing-torture: rcu_torture_read_exit: Start of test
> [  106.082543] tasks-tracing-torture: rcu_torture_read_exit: Start of episode
> [  106.105552] rcutorture: duplicated callback was invoked.
> [  106.105567] rcutorture: duplicated callback was invoked.
> [  106.111269] rcutorture: WARN: Duplicate call_tasks-tracing() test complete.
>
> Thanks
> Zqiang
>
> >
> > Or do you have a use case that needs to silence these warnings?
> >
> >                                                         Thanx, Paul
> >
> > > +                             (!cur_ops->call || !cur_ops->cb_barrier)))
> > >               return;
> > >
> > >       struct rcu_head *rhp = kmalloc(sizeof(*rhp), GFP_KERNEL);
> > > --
> > > 2.17.1
> > >