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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87v82u52a1.fsf@oracle.com>
Date: Thu, 30 May 2024 16:05:26 -0700
From: Ankur Arora <ankur.a.arora@...cle.com>
To: paulmck@...nel.org
Cc: Peter Zijlstra <peterz@...radead.org>,
        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


Paul E. McKenney <paulmck@...nel.org> writes:

> On Wed, May 29, 2024 at 10:14:04AM +0200, Peter Zijlstra wrote:
>> On Mon, May 27, 2024 at 05:35:02PM -0700, Ankur Arora wrote:
>> > The combination of PREEMPT_RCU=n and (PREEMPT_AUTO=y, preempt=full)
>> > works at cross purposes: the RCU read side critical sections disable
>> > preemption, while preempt=full schedules eagerly to minimize
>> > latency.
>> >
>> > Warn if the user is switching to full preemption with PREEMPT_RCU=n.
>> >
>> > Cc: Ingo Molnar <mingo@...hat.com>
>> > Cc: Peter Zijlstra <peterz@...radead.org>
>> > Cc: Juri Lelli <juri.lelli@...hat.com>
>> > Cc: Vincent Guittot <vincent.guittot@...aro.org>
>> > Suggested-by: Paul E. McKenney <paulmck@...nel.org>
>> > Link: https://lore.kernel.org/lkml/842f589e-5ea3-4c2b-9376-d718c14fabf5@paulmck-laptop/
>> > Signed-off-by: Ankur Arora <ankur.a.arora@...cle.com>
>> > ---
>> >  kernel/sched/core.c | 4 ++++
>> >  1 file changed, 4 insertions(+)
>> >
>> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> > index d7804e29182d..df8e333f2d8b 100644
>> > --- a/kernel/sched/core.c
>> > +++ b/kernel/sched/core.c
>> > @@ -8943,6 +8943,10 @@ static void __sched_dynamic_update(int mode)
>> >  		break;
>> >
>> >  	case preempt_dynamic_full:
>> > +		if (!IS_ENABLED(CONFIG_PREEMPT_RCU))
>> > +			pr_warn("%s: preempt=full is not recommended with CONFIG_PREEMPT_RCU=n",
>> > +				PREEMPT_MODE);
>> > +
>>
>> Yeah, so I don't believe this is a viable strategy.
>>
>> Firstly, none of these RCU patches are actually about the whole LAZY
>> preempt scheme, they apply equally well (arguably better) to the
>> existing PREEMPT_DYNAMIC thing.
>>
>> Secondly, esp. with the LAZY thing, you are effectively running FULL at
>> all times. It's just that some of the preemptions, typically those of
>> the normal scheduling class are somewhat delayed. However RT/DL classes
>> are still insta preempt.
>>
>> Meaning that if you run anything in the realtime classes you're running
>> a fully preemptible kernel. As such, RCU had better be able to deal with
>> it.
>>
>> So no, I don't believe this is right.
>
> At one point, lazy preemption selected PREEMPT_COUNT (which I am
> not seeing in this version, perhaps due to blindness on my part).
> Of course, selecting PREEMPT_COUNT would result in !PREEMPT_RCU kernel's
> rcu_read_lock() explicitly disabling preemption, thus avoiding preemption
> (including lazy preemption) in RCU read-side critical sections.

That should be still happening, just transitively. PREEMPT_AUTO selects
PREEMPT_BUILD, which selects PREEMPTION, and that in turn selects
PREEMPT_COUNT.


--
ankur