linux-kernel - Re: [PATCH v2 16/35] preempt,rcu: warn on PREEMPT

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: Mon, 17 Jun 2024 08:54:49 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Ankur Arora <ankur.a.arora@...cle.com>, linux-kernel@...r.kernel.org,
	tglx@...utronix.de, torvalds@...ux-foundation.org,
	rostedt@...dmis.org, mark.rutland@....com, juri.lelli@...hat.com,
	joel@...lfernandes.org, raghavendra.kt@....com,
	sshegde@...ux.ibm.com, boris.ostrovsky@...cle.com,
	konrad.wilk@...cle.com, Ingo Molnar <mingo@...hat.com>,
	Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: [PATCH v2 16/35] preempt,rcu: warn on PREEMPT_RCU=n, preempt=full

On Thu, Jun 06, 2024 at 06:38:57AM -0700, Paul E. McKenney wrote:
> On Thu, Jun 06, 2024 at 01:53:25PM +0200, Peter Zijlstra wrote:
> > On Thu, May 30, 2024 at 04:20:26PM -0700, Paul E. McKenney wrote:
> > 
> > > My selfish motivation here is to avoid testing this combination unless
> > > and until someone actually has a good use for it.
> > 
> > That doesn't make sense, the whole LAZY thing is fundamentally identical
> > to FULL, except it sometimes delays the preemption a wee bit. But all
> > the preemption scenarios from FULL are possible.
> 
> As noted earlier in this thread, this is not the case for non-preemptible
> RCU, which disables preemption across its read-side critical sections.
> In addition, from a performance/throughput viewpoint, it is not just
> the possibility of preemption that matters, but also the probability.
> 
> > As such, it makes far more sense to only test FULL.
> 
> You have considerable work left to do in order to convince me of this one.

On the other hand, it does make sense to select Tiny SRCU for all !SMP
kernels, whether preemptible or not.  And it also makes sense to test
(but not *only* test and definitely *not* support) non-preemptible
RCU running in a preemptible kernel, perhaps as a one-off, perhaps
longer term.  The point being of course that the increased preemption
rate of a fully preemptible kernel should uncover bugs that might appear
in lazy-preemptible kernels only very rarely.

This might have been what you were getting at, and if so, apologies!
But in my defense, you did say "only test FULL" above.  ;-)

							Thanx, Paul