linux-kernel - Re: [PATCH v3 1/2] rcutorture: Perform more frequent testing of ->gpwrap

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]

Message-ID: <5ee46103-caef-46ac-8660-4b9f4bb5e4f0@nvidia.com>
Date: Mon, 14 Apr 2025 11:05:45 -0400
From: Joel Fernandes <joelagnelf@...dia.com>
To: paulmck@...nel.org
Cc: linux-kernel@...r.kernel.org, Frederic Weisbecker <frederic@...nel.org>,
 Neeraj Upadhyay <neeraj.upadhyay@...nel.org>,
 Joel Fernandes <joel@...lfernandes.org>,
 Josh Triplett <josh@...htriplett.org>, Boqun Feng <boqun.feng@...il.com>,
 Uladzislau Rezki <urezki@...il.com>, Steven Rostedt <rostedt@...dmis.org>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Lai Jiangshan <jiangshanlai@...il.com>, Zqiang <qiang.zhang1211@...il.com>,
 Davidlohr Bueso <dave@...olabs.net>, rcu@...r.kernel.org
Subject: Re: [PATCH v3 1/2] rcutorture: Perform more frequent testing of
 ->gpwrap

On 4/10/2025 2:29 PM, Paul E. McKenney wrote:
>> +static int rcu_gpwrap_lag_init(void)
>> +{
>> +	if (gpwrap_lag_cycle_mins <= 0 || gpwrap_lag_active_mins <= 0) {
>> +		pr_alert("rcu-torture: lag timing parameters must be positive\n");
>> +		return -EINVAL;
> When rcutorture is initiated by modprobe, this makes perfect sense.
> 
> But if rcutorture is built in, we have other choices:  (1) Disable gpwrap
> testing and do other testing but splat so that the bogus scripting can
> be fixed, (2) Force default values and splat as before, (3) Splat and
> halt the system.
> 
> The usual approach has been #1, but what makes sense in this case?

If the user deliberately tries to prevent the test, I am Ok with #3 which I
believe is the current behavior. But otherwise #1 is also Ok with me but I don't
feel strongly about doing that.

If we want to do #3, it will just involve changing the "return -EINVAL" to
"return 0" but also may need to be doing so only if RCU torture is a built-in.

IMO the current behavior is reasonable than adding more complexity for an
unusual case for a built-in?

On the other hand if the issue is with providing the user with a way to disable
gpwrap testing, that should IMO be another parameter than setting the _mins
parameters to be 0. But I think we may not want this testing disabled since it
is already "self-disabled" for the first 25 miutes.

Thoughts?

Thanks!

 - Joel