netdev - Re: [0/8] netpoll/bridge fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 16 Jun 2010 09:01:04 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	David Miller <davem@...emloft.net>, herbert@...dor.apana.org.au,
	shemminger@...tta.com, mst@...hat.com, frzhang@...hat.com,
	netdev@...r.kernel.org, amwang@...hat.com, mpm@...enic.com
Subject: Re: [0/8] netpoll/bridge fixes

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 :
> > On Wed, Jun 16, 2010 at 04:58:59AM +0200, Eric Dumazet wrote:
> > > 
> > > 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().
> > 
> > > 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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html