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: Tue, 18 Jun 2024 09:29:24 -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 Mon, Jun 17, 2024 at 08:54:49AM -0700, Paul E. McKenney wrote:
> 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.

Except that testing made a liar out of me.  SRCU priority boosting would
be required.  So this one is also strictly for pre-testing lazy
preemption.

As usual, it seemed like a good idea at the time...  ;-)

							Thanx, Paul

>                                       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