From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: David Howells <dhowells@redhat.com>
Cc: 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: Tue, 30 Mar 2010 17:08:32 -0700 [thread overview]
Message-ID: <20100331000832.GQ2513@linux.vnet.ibm.com> (raw)
In-Reply-To: <21972.1269993064@redhat.com>
On Wed, Mar 31, 2010 at 12:51:04AM +0100, David Howells wrote:
> 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.
How about Eric's suggestion of rcu_dereference_protected()? That name
doesn't imply a lock, which as you say above, isn't always needed to
keep the structure from changing.
Thanx, Paul
next prev parent reply other threads:[~2010-03-31 0:08 UTC|newest]
Thread overview: 48+ 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
[not found] ` <20100318133302.29754.1584.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2010-03-19 2:25 ` Paul E. McKenney
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 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:04 ` Eric Dumazet
2010-03-30 17:25 ` Paul E. McKenney
2010-03-30 17:25 ` Paul E. McKenney
2010-03-30 23:51 ` David Howells
2010-03-31 0:08 ` Paul E. McKenney [this message]
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 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
[not found] ` <1271026643.6620.37.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-04-12 16:47 ` Paul E. McKenney
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=20100331000832.GQ2513@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=Trond.Myklebust@netapp.com \
--cc=dhowells@redhat.com \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.