From: Al Viro <viro@ZenIV.linux.org.uk>
To: Kinglong Mee <kinglongmee@gmail.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
linux-fsdevel@vger.kernel.org, NeilBrown <neilb@suse.de>,
Trond Myklebust <trond.myklebust@primarydata.com>
Subject: Re: [PATCH 10/10 v6] nfsd: Allows user un-mounting filesystem where nfsd exports base on
Date: Wed, 1 Jul 2015 06:47:51 +0100 [thread overview]
Message-ID: <20150701054751.GB17109@ZenIV.linux.org.uk> (raw)
In-Reply-To: <558C121A.3020109@gmail.com>
On Thu, Jun 25, 2015 at 10:37:14PM +0800, Kinglong Mee wrote:
> +static void expkey_validate(struct cache_head *h)
> +{
> + struct svc_expkey *key = container_of(h, struct svc_expkey, h);
> +
> + if (!test_bit(CACHE_VALID, &key->h.flags) ||
> + test_bit(CACHE_NEGATIVE, &key->h.flags))
> + return;
> +
> + if (atomic_read(&h->ref.refcount) == 1) {
> + mutex_lock(&key->ek_mutex);
... followed by kref_get(&h->ref) in caller
> + if (atomic_read(&h->ref.refcount) == 2) {
> + mutex_lock(&key->ek_mutex);
... followed by kref_put() in caller.
Suppose two threads call cache_get() at the same time. Refcount is 1.
Depending on the timing you get either one or both grabbing vfsmount
references. Whichever variant matches the one you want, there is no way
to tell one from another afterwards and they *do* differ in the resulting
vfsmount refcount changes.
Similar to that, suppose the refcount is 3 and two threads call cache_put()
at the same time. If one of them gets through the entire thing (including
kref_put()) before the other gets to atomic_read(), you get the second
see refcount 2 and do that mntput(). If not, _nobody_ will ever see refcount
2 and mntput() is not done.
How can that code possibly be correct? This kind of splitting atomic_read
from increment/decrement (and slapping a sleeping operation in between,
no less) is basically never right. Not unless you have everything serialized
on the outside and do not need the atomic in the first place, which doesn't
seem to be the case here.
next prev parent reply other threads:[~2015-07-01 5:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-25 14:17 [PATCH 00/10 v6] NFSD: Pin to vfsmount for nfsd exports cache Kinglong Mee
2015-06-25 14:18 ` [PATCH 01/10 v6] fs_pin: Initialize value for fs_pin explicitly Kinglong Mee
2015-06-25 14:19 ` [PATCH 02/10 v6] fs_pin: Export functions for specific filesystem Kinglong Mee
2015-06-25 14:19 ` [PATCH 03/10 v6] path: New helpers path_get_pin/path_put_unpin for path pin Kinglong Mee
2015-06-25 14:21 ` [PATCH 04/10 v6] fs: New helper legitimize_mntget() for getting a legitimize mnt Kinglong Mee
2015-06-25 14:25 ` [PATCH 05/10 v6] sunrpc: Store cache_detail in seq_file's private directly Kinglong Mee
2015-06-25 14:27 ` [PATCH 06/10 v6] sunrpc/nfsd: Remove redundant code by exports seq_operations functions Kinglong Mee
2015-06-25 14:29 ` [PATCH 07/10 v6] sunrpc: Switch to using list_head instead single list Kinglong Mee
2015-06-25 14:34 ` [PATCH 08/10] sunrpc: New helper cache_delete_entry for deleting cache_head directly Kinglong Mee
2015-06-25 14:36 ` [PATCH 09/10 v6] sunrpc: Support validate/invalidate for reference change in cache_detail Kinglong Mee
2015-06-25 14:37 ` [PATCH 10/10 v6] nfsd: Allows user un-mounting filesystem where nfsd exports base on Kinglong Mee
2015-07-01 5:47 ` Al Viro [this message]
2015-07-02 15:17 ` Kinglong Mee
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=20150701054751.GB17109@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=bfields@fieldses.org \
--cc=kinglongmee@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=trond.myklebust@primarydata.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