linux-kernel - Re: [PATCH] rcutorture: Skip debug object testing for cur_ops without ->debug

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: <CALm+0cXdHU4qa175SAx3GaktdLWrchS_xcJcidmvmPtm0twjng@mail.gmail.com>
Date: Tue, 4 Jun 2024 11:30:08 +0800
From: Z qiang <qiang.zhang1211@...il.com>
To: paulmck@...nel.org
Cc: frederic@...nel.org, neeraj.upadhyay@...nel.org, joel@...lfernandes.org, 
	urezki@...il.com, rcu@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rcutorture: Skip debug object testing for cur_ops without
 ->debug_objects set

>
> On Tue, Jun 04, 2024 at 10:19:08AM +0800, Z qiang wrote:
> > >
> > > On Mon, Jun 03, 2024 at 12:55:30PM +0800, Z qiang wrote:
> > > > >
> > > > > >
> > > > > > 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@...il.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  ;) .
> > >
> > > Understood.
> > >
> > > It is just that in my experience, it is a good thing for rcutorture to
> > > splat when asked to do something that it cannot do.  Or do you have a
> > > use case where this is problematic?
> > >
> >
> > Hi, Paul
> >
> >
> > This is a scene I mentioned before:
> >
> > 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.
> >
> > for call_rcu*()  that does not support double call checking, if
> > continue to test,
> > "rcutorture: duplicated callback was invoked". will output,
> > I just want to avoid the output of this error message :)
>
> OK, but then why not just avoid setting rcutorture.object_debug for
> the torture_type values that do not support it?

OK, understand.

Thanks
Zqiang

>
>                                                         Thanx, Paul
>
> > Thanks
> > Zqiang
> >
> >
> > > I don't count the fuzzers because they are supposed to avoid specifying
> > > things that are supposed to fail.  ;-)
> > >
> > >                                                         Thanx, Paul
> > >
> > > > 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
> > > > > > >