From: "Paul E. McKenney" <paulmck@kernel.org>
To: Trond Myklebust <trondmy@hammerspace.com>
Cc: "madhuparnabhowmik04@gmail.com" <madhuparnabhowmik04@gmail.com>,
"linux-kernel-mentees@lists.linuxfoundation.org"
<linux-kernel-mentees@lists.linuxfoundation.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"rcu@vger.kernel.org" <rcu@vger.kernel.org>,
"anna.schumaker@netapp.com" <anna.schumaker@netapp.com>,
"joel@joelfernandes.org" <joel@joelfernandes.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] fs: nfs: dir.c: Fix sparse error
Date: Fri, 6 Dec 2019 10:24:14 -0800 [thread overview]
Message-ID: <20191206182414.GH2889@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <2ec21ec537144bb3c0d5fbdaf88ea022d07b7ff8.camel@hammerspace.com>
On Fri, Dec 06, 2019 at 05:52:10PM +0000, Trond Myklebust wrote:
> Hi Paul,
>
> On Fri, 2019-12-06 at 08:02 -0800, Paul E. McKenney wrote:
> > On Fri, Dec 06, 2019 at 08:46:40PM +0530,
> > madhuparnabhowmik04@gmail.com wrote:
> > > From: Madhuparna Bhowmik <madhuparnabhowmik04@gmail.com>
> > >
> > > This patch fixes the following errors:
> > > fs/nfs/dir.c:2353:14: error: incompatible types in comparison
> > > expression (different address spaces):
> > > fs/nfs/dir.c:2353:14: struct list_head [noderef] <asn:4> *
> > > fs/nfs/dir.c:2353:14: struct list_head *
> > >
> > > caused due to directly accessing the prev pointer of
> > > a RCU protected list.
> > > Accessing the pointer using the macro list_prev_rcu() fixes this
> > > error.
> > >
> > > Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik04@gmail.com>
> > > ---
> > > fs/nfs/dir.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
> > > index e180033e35cf..2035254cc283 100644
> > > --- a/fs/nfs/dir.c
> > > +++ b/fs/nfs/dir.c
> > > @@ -2350,7 +2350,7 @@ static int nfs_access_get_cached_rcu(struct
> > > inode *inode, const struct cred *cre
> > > rcu_read_lock();
> > > if (nfsi->cache_validity & NFS_INO_INVALID_ACCESS)
> > > goto out;
> > > - lh = rcu_dereference(nfsi->access_cache_entry_lru.prev);
> > > + lh = rcu_dereference(list_prev_rcu(&nfsi-
> > > >access_cache_entry_lru));
> >
> > And as noted in the earlier email, what is preventing concurrent
> > insertions into and deletions from this list?
> >
> > o This use of list_move_tail() is OK because it does not poison.
> > Though it isn't being all that friendly to lockless access to
> > ->prev -- no WRITE_ONCE() in list_move_tail().
> >
> > o The use of list_add_tail() is not safe with RCU readers, though
> > they do at least partially compensate via use of smp_wmb()
> > in nfs_access_add_cache() before calling
> > nfs_access_add_rbtree().
> >
> > o The list_del() near the end of nfs_access_add_rbtree() will
> > poison the ->prev pointer. I don't see how this is safe given
> > the
> > possibility of a concurrent call to
> > nfs_access_get_cached_rcu().
>
> The pointer nfsi->access_cache_entry_lru is the head of the list, so it
> won't get poisoned. Furthermore, the objects it points to are freed
> using kfree_rcu(), so they will survive as long as we hold the rcu read
> lock. The object's cred pointers also points to something that is freed
> in an rcu-safe manner.
>
> The problem here is rather that a racing list_del() can cause nfsi-
> >access_cache_entry_lru to be empty, which is presumably why Neil added
> that check plus the empty cred pointer check in the following line.
>
> The barrier semantics may be suspect, although the spin unlock after
> list_del() should presumably guarantee release semantics?
Ah, OK, so you are only ever using ->prev only from the head of the list,
and presumably never do list_del() on the head itself. (Don't laugh,
this does really happen as a way to remove the entire list, though
perhaps with list_del_init() rather than list_del().)
Maybe we should have a list_tail_rcu() that is only expected to work
on the head of the list?
Thanx, Paul
next prev parent reply other threads:[~2019-12-06 18:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-06 15:16 [PATCH 2/2] fs: nfs: dir.c: Fix sparse error madhuparnabhowmik04
2019-12-06 16:00 ` Joel Fernandes
2019-12-06 16:12 ` Paul E. McKenney
2019-12-06 16:02 ` Paul E. McKenney
2019-12-06 17:52 ` Trond Myklebust
2019-12-06 18:24 ` Paul E. McKenney [this message]
2019-12-06 18:28 ` Trond Myklebust
2019-12-06 18:45 ` Paul E. McKenney
2019-12-12 21:55 ` Joel Fernandes
2019-12-13 1:16 ` 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=20191206182414.GH2889@paulmck-ThinkPad-P72 \
--to=paulmck@kernel.org \
--cc=anna.schumaker@netapp.com \
--cc=joel@joelfernandes.org \
--cc=linux-kernel-mentees@lists.linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=madhuparnabhowmik04@gmail.com \
--cc=rcu@vger.kernel.org \
--cc=trondmy@hammerspace.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).