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 :

quoted

On Wed, Jun 16, 2010 at 04:58:59AM +0200, Eric Dumazet wrote:

quoted

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().

quoted

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