[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20111129174146.GF2331@linux.vnet.ibm.com>
Date: Tue, 29 Nov 2011 09:41:47 -0800
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
dipankar@...ibm.com, akpm@...ux-foundation.org,
mathieu.desnoyers@...ymtl.ca, josh@...htriplett.org,
niv@...ibm.com, tglx@...utronix.de, rostedt@...dmis.org,
Valdis.Kletnieks@...edu, dhowells@...hat.com,
eric.dumazet@...il.com, darren@...art.com, patches@...aro.org
Subject: Re: [PATCH RFC tip/core/rcu 24/28] rcu: Introduce bulk reference
count
On Tue, Nov 29, 2011 at 02:33:35PM +0100, Peter Zijlstra wrote:
> 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.
OK, I will cross that test off my list for today. ;-)
> Still uprobes can do:
>
> local_irq_save(flags);
> __srcu_read_lock(&mr_srcu_domain);
> local_irq_restore(flags);
And this is exactly what the bulkref stuff does, so we at least agree
on the implementation.
> 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()
Good point, the _raw suffix is used elsewhere in RCU for "turn off lockdep",
so it makes sense to use it here as well.
I will change to srcu_read_lock_raw() and srcu_read_unlock_raw(). And
that has the added benefit of getting rid of the alternative names for
the initialization and cleanup functions, so sounds good! Thank you!
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/
Powered by blists - more mailing lists