On Tue, Feb 17, 2015 at 03:29:53PM +0100, Sebastian Andrzej Siewior wrote:

* Paul E. McKenney | 2014-12-03 13:19:11 [-0800]:

quoted

quoted

Is that not actually a bug indepedent of RT ? 
without the rcu_read_lock/unlock who says that the 
rcu_dereference is still valid at this point ? 
I though that if bh are already disabled you still
need the read_lock. disabled bh would allow to "downgrad" 
the rcu_read_lock_bh to rcu_read_lock but you still need it.

In vanilla kernels, anything that disables BH acts as rcu_read_lock_bh().
So yes, you can have cases where rcu_read_lock_bh() is needed only in
the -rt kernel.

But it won't hurt mainline using rcu_read_lock_bh() around
rcu_dereference_bh() right?

Using rcu_read_lock_bh() around rcu_dereference_bh() is completely
legal, yes.

I am not going to apply this because that code is gone shortly after
v3.14 was released. The fm10k however does the same thing so atleast RCU
knows when to scream :)

That is good, because it has been a good long time since I could
reasonably review all code in the kernel that uses RCU.  ;-)

							Thanx, Paul

Sebastian