Re: [PATCH v3.14-rt] netpoll: guard the access to dev->npinfo with rcu_read_lock/unlock_bh() for CONFIG_PREEMPT_RT_FULL=y

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

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
>