From: David Howells <dhowells@redhat.com>
To: paulmck@linux.vnet.ibm.com
Cc: dhowells@redhat.com, Eric Dumazet <eric.dumazet@gmail.com>,
Trond.Myklebust@netapp.com, linux-nfs@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] NFS: Fix RCU warnings in nfs_inode_return_delegation_noreclaim() [ver #2]
Date: Wed, 31 Mar 2010 00:51:04 +0100 [thread overview]
Message-ID: <21972.1269993064@redhat.com> (raw)
In-Reply-To: <20100330164912.GG2513@linux.vnet.ibm.com>
Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> Which it is, as long as the lock is held.
However, in one of the situations I'm thinking of, no lock is held. All that
is being tested is whether the pointer to some RCU-protected data is either
NULL or non-NULL. For example:
@@ -345,7 +346,7 @@ int nfs_inode_return_delegation(struct inode *inode)
struct nfs_delegation *delegation;
int err = 0;
- if (rcu_dereference(nfsi->delegation) != NULL) {
+ if (nfsi->delegation != NULL) {
spin_lock(&clp->cl_lock);
delegation = nfs_detach_delegation_locked(nfsi, NULL);
spin_unlock(&clp->cl_lock);
No lock - RCU or spinlock - is held over the check of nfsi->delegation - which
causes lockdep to complain about an unguarded rcu_dereference().
However, the use of rcu_dereference() here is unnecessary with respect to the
interpolation (where appropriate) of a memory barrier because there is no
second memory access against which to order.
That said, the memory access is repeated inside nfs_detach_delegation_locked(),
which again was wrapped in an rcu_dereference():
static struct nfs_delegation *nfs_detach_delegation_locked(struct nfs_inode *nfsi, const nfs4_stateid *stateid)
{
- struct nfs_delegation *delegation = rcu_dereference(nfsi->delegation);
+ struct nfs_delegation *delegation = nfsi->delegation;
if (delegation == NULL)
goto nomatch;
which was not necessary for its memory barrier interpolation properties in this
case because of the spin_lock() the caller now holds.
Your suggestion of using rcu_dereference_check() in both these places would
result in two unnecessary memory barriers on something like an Alpha CPU.
How about:
static struct nfs_delegation *nfs_detach_delegation_locked(struct nfs_inode *nfsi, const nfs4_stateid *stateid)
{
struct nfs_delegation *delegation =
rcu_locked_dereference(nfsi->delegation);
...
}
where rcu_locked_dereference() only does the lockdep magic and the dereference,
and does not include a memory barrier. The documentation of such a function
would note this may only be used when the pointer is guarded by an exclusive
lock to prevent it from changing.
And then:
int nfs_inode_return_delegation(struct inode *inode)
{
struct nfs_client *clp = NFS_SERVER(inode)->nfs_client;
struct nfs_inode *nfsi = NFS_I(inode);
struct nfs_delegation *delegation;
int err = 0;
if (rcu_pointer_not_null(nfsi->delegation)) {
spin_lock(&clp->cl_lock);
delegation = nfs_detach_delegation_locked(nfsi, NULL);
spin_unlock(&clp->cl_lock);
if (delegation != NULL) {
nfs_msync_inode(inode);
err = __nfs_inode_return_delegation(inode, delegation, 1);
}
}
return err;
}
where rcu_pointer_not_null() simply tests the value of the pointer, casting
away the sparse RCU annotation and not doing the lockdep check and not
including a barrier. It would not return the value of the pointer, thus
preventing you from needing the barrier as a result.
David
next prev parent reply other threads:[~2010-03-30 23:52 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-18 13:33 [PATCH] NFS: Fix RCU warnings in nfs_inode_return_delegation_noreclaim() [ver #2] David Howells
2010-03-19 2:25 ` Paul E. McKenney
2010-03-29 19:02 ` David Howells
2010-03-29 19:21 ` Paul E. McKenney
2010-03-29 20:15 ` David Howells
2010-03-29 20:26 ` Eric Dumazet
2010-03-29 21:05 ` Paul E. McKenney
2010-03-29 22:22 ` David Howells
2010-03-29 22:36 ` Paul E. McKenney
2010-03-29 22:59 ` David Howells
2010-03-29 23:26 ` Paul E. McKenney
2010-03-30 15:40 ` Paul E. McKenney
2010-03-30 16:39 ` David Howells
2010-03-30 16:49 ` Paul E. McKenney
2010-03-30 17:04 ` Eric Dumazet
2010-03-30 17:25 ` Paul E. McKenney
2010-03-30 23:51 ` David Howells [this message]
2010-03-31 0:08 ` Paul E. McKenney
2010-03-31 14:04 ` David Howells
2010-03-31 15:16 ` Paul E. McKenney
2010-03-31 17:37 ` David Howells
2010-03-31 18:30 ` Paul E. McKenney
2010-03-31 18:32 ` Eric Dumazet
2010-03-31 22:53 ` David Howells
2010-04-01 1:29 ` Paul E. McKenney
2010-04-01 11:45 ` David Howells
2010-04-01 14:39 ` Paul E. McKenney
2010-04-01 14:46 ` David Howells
2010-04-05 17:57 ` Paul E. McKenney
2010-04-06 9:30 ` David Howells
2010-04-06 16:14 ` David Howells
2010-04-06 17:29 ` Paul E. McKenney
2010-04-06 19:34 ` David Howells
2010-04-07 0:02 ` Paul E. McKenney
2010-04-07 13:22 ` David Howells
2010-04-07 15:57 ` Paul E. McKenney
2010-04-07 16:35 ` RCU condition checks David Howells
2010-04-07 17:10 ` Paul E. McKenney
2010-04-11 22:57 ` Trond Myklebust
2010-04-12 16:47 ` Paul E. McKenney
2010-03-30 16:37 ` [PATCH] NFS: Fix RCU warnings in nfs_inode_return_delegation_noreclaim() [ver #2] David Howells
2010-03-30 17:01 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=21972.1269993064@redhat.com \
--to=dhowells@redhat.com \
--cc=Trond.Myklebust@netapp.com \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).