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] [thread-next>] [day] [month] [year] [list]

Date: Tue, 28 May 2024 12:03:06 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Zqiang <qiang.zhang1211@...il.com>
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, 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?

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
>