Re: [0/8] netpoll/bridge fixes

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Wed, Jun 16, 2010 at 08:21:21AM +0200, Eric Dumazet wrote:
> Le mardi 15 juin 2010 à 22:08 -0700, Paul E. McKenney a écrit :
> > On Wed, Jun 16, 2010 at 04:58:59AM +0200, Eric Dumazet wrote:
> > > 
> > > Paul, could you please explain if current lockdep rules are correct, or could be relaxed ?
> > > 
> > > I thought :
> > > 
> > > rcu_read_lock_bh();
> > > 
> > > was a shorthand to
> > > 
> > > local_disable_bh();
> > > rcu_read_lock();
> > 
> > In CONFIG_TREE_RCU and CONFIG_TINY_RCU, rcu_read_lock_bh() is actually
> > shorthand for only local_disable_bh().  Therefore, rcu_dereference()
> > will scream if only rcu_read_lock_bh() is held.
> > 
> > However, in CONFIG_PREEMPT_TREE_RCU, rcu_read_lock_bh() is its own
> > mechanism that does local_disable_bh() but has its own set of grace
> > periods, independent of those of rcu_read_lock().
> > 
> > > Why lockdep is not able to make a correct diagnostic ?
> > 
> > Here is the situation I am concerned about:
> > 
> > o	Task 0 does rcu_read_lock(), then p=rcu_dereference_bh().
> > 	If we make the change you are asking for, rcu_dereference_bh()
> > 	is OK with this.
> > 
> > o	Task 0 now is preempted before finishing its RCU read-side
> > 	critical section.
> > 
> > o	Task 1 removes the data element referenced by pointer p,
> > 	then invokes synchronize_rcu_bh().
> > 
> > o	Task 0 does not block synchronize_rcu_bh(), so the grace
> > 	period completes.
> > 
> > o	Task 1 frees up the data element referenced by pointer p,
> > 	which might be reallocated as some other type, unmapped,
> > 	or whatever else.
> > 
> > o	Task 0 resumes, and is sadly disappointed when the data
> > 	element referenced by pointer p has been swept out from
> > 	under it.
> > 
> > Or am I missing something here?
> > 
> 
> Nice thing with RCU is that I learn new things every day ;)
> 
> Thanks Paul, I'll try to remember all the details ! ;)

;-)

But just to be clear...  All but one use of RCU-bh is in networking,
so if you guys need something different from RCU-bh, let's talk!

And I learn something new about RCU every day as well.  One of today's
lessons is that networking is no longer the only user of RCU-bh.  ;-)

							Thanx, Paul