linux-kernel - Re: [PATCH] NFS: Fix RCU warnings in nfs_inode_return_delegation

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: <20100407155729.GA2481@linux.vnet.ibm.com>
Date:	Wed, 7 Apr 2010 08:57:29 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	David Howells <dhowells@...hat.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>, Trond.Myklebust@...app.com,
	linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] NFS: Fix RCU warnings in
 nfs_inode_return_delegation_noreclaim() [ver #2]

On Wed, Apr 07, 2010 at 02:22:41PM +0100, David Howells wrote:
> Paul E. McKenney <paulmck@...ux.vnet.ibm.com> wrote:
> 
> > +#define rcu_access_pointer(p, c) \
> 
> Why is there a need for 'c'?

An example use is where rcu_access_pointer() is legal because we are
either initializing or cleaning up, so that no other CPU has access
to the pointer.  In these cases, you might do something like:

	q = rcu_access_pointer(p->a, p->refcnt == 0);

> > +#define rcu_dereference_protect(p, c) \
> 
> I'd prefer rcu_dereference_protected(), I think.  This macro doesn't protect
> anything.  Also, again, why the need for 'c'?

Agreed on rcu_dereference_protected().  I succumbed to a fit of "make
the identifier shorter", please accept my apologies.

> For instance, in:
> 
> 	static struct nfs_delegation *nfs_detach_delegation_locked(struct nfs_inode *nfsi, const nfs4_stateid *stateid)
> 	{
> 		struct nfs_delegation *delegation =
> 			rcu_dereference_protected(nfsi->delegation, ????);
> 
> what would be the condition?  That the spinlock is held?  That's a condition
> for calling the function.

Yep, that the spinlock is held.  I agree that it is a bit obvious in
this case, but I have come across a number of RCU uses where the lock
in question was acquired many function calls removed from the access,
and where there other locks were held for other purposes.

> And in:
> 
> 	void nfs_inode_return_delegation_noreclaim(struct inode *inode)
> 	{
> 		struct nfs_client *clp = NFS_SERVER(inode)->nfs_client;
> 		struct nfs_inode *nfsi = NFS_I(inode);
> 		struct nfs_delegation *delegation;
> 
> 		if (rcu_access_pointer(nfsi->delegation, ????) != NULL) {
> 
> what would be the condition here?  There's no lock to check - that's the whole
> point of the macro.  I also can't give it nfsi->delegation to check as the
> value may change between the two accesses.

I suggest something like the following:

		/* protected by double-check lock pattern. */
		if (rcu_access_pointer(nfsi->delegation, 1) != NULL) {

							Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/