linux-kernel - Re: [PATCH RFC tip/core/rcu 0/16] Prototype RCU usable from idle, exception, offline

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: <20200313144145.GA31604@lenoir>
Date:   Fri, 13 Mar 2020 15:41:46 +0100
From:   Frederic Weisbecker <frederic@...nel.org>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     mutt@...lmck-ThinkPad-P72, rcu@...r.kernel.org,
        linux-kernel@...r.kernel.org, kernel-team@...com, mingo@...nel.org,
        jiangshanlai@...il.com, dipankar@...ibm.com,
        akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
        josh@...htriplett.org, tglx@...utronix.de, peterz@...radead.org,
        rostedt@...dmis.org, dhowells@...hat.com, edumazet@...gle.com,
        fweisbec@...il.com, oleg@...hat.com, joel@...lfernandes.org
Subject: Re: [PATCH RFC tip/core/rcu 0/16] Prototype RCU usable from idle,
 exception, offline

On Thu, Mar 12, 2020 at 11:16:18AM -0700, Paul E. McKenney wrote:
> Hello!
> 
> This series provides two variants of Tasks RCU, a rude variant inspired
> by Steven Rostedt's use of schedule_on_each_cpu(), and a tracing variant
> requested by the BPF folks and perhaps also of use for other tracing
> use cases.
> 
> The tracing variant has explicit read-side markers to permit finite grace
> periods even given in-kernel loops in PREEMPT=n builds It also protects
> code in the idle loop, on exception entry/exit paths, and on the various
> CPU-hotplug online/offline code paths, thus having protection properties
> similar to SRCU.  However, unlike SRCU, this variant avoids expensive
> instructions in the read-side primitives, thus having read-side overhead
> similar to that of preemptible RCU.
> 
> There are of course downsides.  The grace-period code can send IPIs to
> CPUs, even when those CPUs are in the idle loop or in nohz_full userspace.
> It is necessary to scan the full tasklist, much as for Tasks RCU.  There
> is a single callback queue guarded by a single lock, again, much as for
> Tasks RCU.  If needed, these downsides can be at least partially remedied

So what we trade to fix the issues we are having with tracing against extended
grace periods, we lose in CPU isolation. That worries me a bit as tracing can
be thoroughly used with nohz_full and CPU isolation.