linux-kernel - Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section?

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, 9 Sep 2013 09:22:15 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	mathieu.desnoyers@...icios.com, josh@...htriplett.org,
	niv@...ibm.com, tglx@...utronix.de, dhowells@...hat.com,
	edumazet@...gle.com, darren@...art.com, sbw@....edu
Subject: Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical
 section?

On Mon, Sep 09, 2013 at 09:55:11AM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 06:46:05 -0700
> "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> wrote:
> 
> 
> > > Also, if its per-task, why don't we have this in the task struct? The
> > > current scheme makes the context switch more expensive -- is this the
> > > right trade-off?
> > 
> > There are constraints based on the task, but RCU really is
> > paying attention to CPUs, not than tasks.  (With the exception of
> > TREE_PREEMPT_RCU, which does keep lists of tasks that it has to pay
> > attention to, namely those that have been preempted within their current
> > RCU read-side critical section.)
> 
> Conceptually wise, RCU keeps track of task state, not CPU state. In all
> your diagrams in your presentations, where you talk about grace periods
> and quiescent states, you show tasks, not CPUs.
> 
> RCU's implementation is based on CPUs, and only when rcu_read_lock()
> prevents preemption. As you stated above, TREE_PREEMPT_RCU needs to
> keep track of tasks.

Actually, in TINY_RCU and TREE_RCU, preemption is disabled to begin
with, so that rcu_read_lock() doesn't need to do anything.  I left
the preempt_disable() in rcu_read_lock() and the preempt_enable() in
rcu_read_unlock() in case we ever have need to run either TINY_RCU or
TREE_RCU in a CONFIG_PREEPT=y kernel.

That said, TREE_PREEMPT_RCU's implementation does track tasks sometimes,
but only in the (hopefully) uncommon case where an RCU read-side critical
section is preempted.

However, the API we are arguing about is deep within the implementation.
It is not at the level of rcu_read_lock().  It is something that should
not have that many invocations -- after all, the things using it are
binding themselves unusually close to RCU.

> I think you are too deep into the implementation, that you are
> forgetting the concept that you created :-)

Like I said before (though admittedly after you wrote the above), the
implementation came first and the concepts much later.  ;-)

							Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/