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]

Message-ID: <1276669281.19249.62.camel@edumazet-laptop>
Date:	Wed, 16 Jun 2010 08:21:21 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	paulmck@...ux.vnet.ibm.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

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 ! ;)



--
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