lkml.org 
[lkml]   [2011]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH RFC tip/core/rcu 24/28] rcu: Introduce bulk reference count
From
Date
On Mon, 2011-11-28 at 19:35 +0100, Peter Zijlstra wrote:
> On Mon, 2011-11-28 at 10:31 -0800, Paul E. McKenney wrote:
> > > local_irq_save(flags);
> > > srcu_read_lock(&my_srcu_domain);
> > > local_irq_restore(flags);
> > >
> > > and
> > >
> > > local_irq_save(flags);
> > > srcu_read_unlock(&my_srcu_domain);
> > > local_irq_restore(flags)
> > >
> > > Doesn't look to be too hard, or confusing.
> >
> > Ah, OK, I was under the mistaken impression that lockdep would splat
> > if you did (for example) srcu_read_lock() in an exception handler and
> > srcu_read_unlock() in the context of the task that took the exception.
>
> I don't think it will, lockdep does very little actual validation on the
> RCU locks other than recording they're held. But if they do, the planned
> TODO item will get inversed.
>
> Should be easy enough to test I guess.

OK, so I had me a little peek at lockdep and you're right, it will
complain.

Still uprobes can do:

local_irq_save(flags);
__srcu_read_lock(&mr_srcu_domain);
local_irq_restore(flags);

However if you object to exposing the __srcu functions (which I can
understand) you could expose these two functions as
srcu_read_{,un}lock_raw() or so, to mirror the non-validation also found
in rcu_dereference_raw()




\
 
 \ /
  Last update: 2011-11-29 14:37    [W:0.115 / U:0.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site