lkml.org 
[lkml]   [2014]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@goodmis.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.



\
 
 \ /
  Last update: 2014-08-07 22:21    [W:0.226 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site