netdev - Re: [PATCH] NETLABEL: Fix an RCU warning

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: <201003291605.48605.paul.moore@hp.com>
Date:	Mon, 29 Mar 2010 16:05:48 -0400
From:	Paul Moore <paul.moore@...com>
To:	paulmck@...ux.vnet.ibm.com
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	David Howells <dhowells@...hat.com>, netdev@...r.kernel.org
Subject: Re: [PATCH] NETLABEL: Fix an RCU warning

On Monday 29 March 2010 11:58:57 am Paul E. McKenney wrote:
> On Mon, Mar 29, 2010 at 11:30:10AM -0400, Paul Moore wrote:
> > On Monday 29 March 2010 11:24:53 am Paul E. McKenney wrote:
> > > On Thu, Mar 25, 2010 at 12:28:04PM +0100, Eric Dumazet wrote:
> > > > Le jeudi 25 mars 2010 à 11:06 +0000, David Howells a écrit :
> > > > > Fix an RCU warning in the netlabel code due to missing rcu read
> > > > > locking around an rcu_dereference() in netlbl_unlhsh_hash() when
> > > > > called from netlbl_unlhsh_netdev_handler():
> > > > > 
> > > > > ===================================================
> > > > > [ INFO: suspicious rcu_dereference_check() usage. ]
> > > > > ---------------------------------------------------
> > > > > net/netlabel/netlabel_unlabeled.c:246 invoked
> > > > > rcu_dereference_check() without protection!

...

> > As Eric pointed out in response to the message above, I believe the
> > solution is to simply remove the rcu_dereference() call in the
> > netlbl_unlhsh_hash() function.
> 
> It would be at the moment, but this will break once Arnd Bergmann gets
> his sparse-based checks done.  With these checks, we decorate RCU-protected
> pointers, and then sparse yells if you access such a pointer without the
> proper rcu_dereference() invocation.

Okay, is there a recommended approach towards accessing RCU-protected pointers 
both under a RCU read lock and under only a spinlock (or similar lock 
construct)?  I know I could do something based on querying the state of the 
RCU/etc. locks but that seems like a hack and could interfere with some of the 
logic used to detect coding problems.

-- 
paul moore
linux @ hp
--
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