On Tue, Feb 17, 2015 at 03:29:53PM +0100, Sebastian Andrzej Siewior wrote: > * Paul E. McKenney | 2014-12-03 13:19:11 [-0800]: > > >> 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
