linux-kernel - Re: [PATCH v3 tip/core/rcu 3/9] rcu: Add synchronous grace-period waiting for RCU-tasks

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: <20140807200813.GB3935@laptop>
Date:	Thu, 7 Aug 2014 22:08:13 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org,
	mingo@...nel.org, laijs@...fujitsu.com, dipankar@...ibm.com,
	akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
	josh@...htriplett.org, tglx@...utronix.de, dhowells@...hat.com,
	edumazet@...gle.com, dvhart@...ux.intel.com, fweisbec@...il.com,
	bobby.prani@...il.com
Subject: Re: [PATCH v3 tip/core/rcu 3/9] rcu: Add synchronous grace-period
 waiting for RCU-tasks

On Thu, Aug 07, 2014 at 03:53:26PM -0400, Steven Rostedt wrote:
> On Thu, 7 Aug 2014 15:49:07 -0400
> Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> 
> > Only voluntary calls to schedule() will be a quiescent state. Preempt
> > doesn't count. And no, function callbacks to not call schedule(),
> > function callbacks should be treated even stricter than interrupt
> > handlers. They should never call schedule() directly or even take any
> > locks. Heck, they should be stricter than NMIs for that matter.
> > 
> > Hence, once something calls schedule() directly, we know that it is not
> > on a trampoline, nor is it going to return to one.
> 
> I should also be a bit clearer here. It's not just function callbacks,
> but anything that adds a trampoline that can be called from any context
> (like for kprobes). The point is, these trampolines that can execute
> anywhere (including in NMIs), must have strict use cases. These are not
> a notifier or other generic operation that normal RCU is fine for.
> These are for really specific cases that require the call_rcu_task() to
> free.
> 
> call_rcu_task() should seldom be used. The only cases really are for
> kprobes and function tracing, and perhaps other dynamic callers.

OK, you've got to start over and start at the beginning, because I'm
really not understanding this..

What is a 'trampoline' and what are you going to use them for.

--
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/