[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-rt-users
Subject:    Re: [PATCH v3.14-rt] netpoll: guard the access to dev->npinfo with rcu_read_lock/unlock_bh() for CON
From:       "Paul E. McKenney" <paulmck () linux ! vnet ! ibm ! com>
Date:       2014-12-03 21:19:11
Message-ID: 20141203211911.GR25340 () linux ! vnet ! ibm ! com
[Download RAW message or body]

On Wed, Dec 03, 2014 at 01:50:20PM +0100, Nicholas Mc Guire wrote:
> On Wed, 03 Dec 2014, Kevin Hao wrote:
> 
> > For vanilla kernel we don't need to invoke rcu_read_lock/unlock_bh
> > explicitly to mark an RCU-bh critical section in the softirq context
> > because bh is already disabled in this case. But for a rt kernel,
> > the commit ("rcu: Merge RCU-bh into RCU-preempt") implements the
> > RCU-bh in term of RCU-preempt. So we have to use
> > rcu_read_lock/unlock_bh() to mark an RCU-bh critical section even in
> > +
> > +#ifdef CONFIG_PREEMPT_RT_FULL
> > +	rcu_read_lock_bh();
> > +#endif
> > +
> > +	npinfo = rcu_dereference_bh(skb->dev->npinfo);
> > +	ret = npinfo && (!list_empty(&npinfo->rx_np) || npinfo->rx_flags);
> > +
> > +#ifdef CONFIG_PREEMPT_RT_FULL
> > +	rcu_read_unlock_bh();
> > +#endif
> 
> 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.

							Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]