All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
	hooanon05@yahoo.co.jp, hch@infradead.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH v2] Fix i_mutex handling in nfsd readdir
Date: Mon, 20 Apr 2009 15:50:08 -0400	[thread overview]
Message-ID: <20090420195008.GE1823@fieldses.org> (raw)
In-Reply-To: <20090419205154.GA18110@fieldses.org>

On Sun, Apr 19, 2009 at 04:51:54PM -0400, bfields wrote:
> On Sun, Apr 19, 2009 at 01:27:49PM +0100, David Woodhouse wrote:
> > Commit 14f7dd63 ("Copy XFS readdir hack into nfsd code") introduced a
> > bug to generic code which had been extant for a long time in the XFS
> > version -- it started to call through into lookup_one_len() and hence
> > into the file systems' ->lookup() methods without i_mutex held on the
> > directory.
> > 
> > This patch fixes it by locking the directory's i_mutex again before
> > calling the filldir functions. The original deadlocks which commit
> > 14f7dd63 was designed to avoid are still avoided, because they were due
> > to fs-internal locking, not i_mutex.
> > 
> > Commit 05f4f678 ("nfsd4: don't do lookup within readdir in recovery
> > code") introduced a similar problem there, which this also addresses.
> > 
> > While we're at it, fix the return type of nfsd_buffered_readdir() which
> > should be a __be32 not an int -- it's an NFS errno, not a Linux errno.
> > And return nfserrno(-ENOMEM) when allocation fails, not just -ENOMEM.
> > Sparse would have caught both of those if it wasn't so busy bitching
> > about __cold__.
> > 
> > Commit 05f4f678 ("nfsd4: don't do lookup within readdir in recovery
> > code") introduced a similar problem with calling lookup_one_len()
> > without i_mutex, which this patch also addresses.
> > 
> > Reported-by: J. R. Okajima <hooanon05@yahoo.co.jp>
> > Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
> > Umm-I-can-live-with-that-by: Al Viro <viro@zeniv.linux.org.uk>
> > ---
> > Still haven't tested the NFSv4 bit -- Bruce?
> 
> Thanks, there's an iterator in there that calls a passed-in function,
> some examples of which were taking the i_mutex--so some fixing up is
> needed.  I'll follow up with a patch once I've got one tested.

Sorry for the delay.  Simpler might be just to drop and reacquire the
mutex each time through nfsd4_list_rec_dir()'s loop, but I'd just as
soon rework the called functions to expect the mutex be held (and get
rid of the unused, probably fragile, clear_clid_dir() in the process).

So the following could be folded in to your patch.

I tested the combined patch over 2.6.30-rc2.  I also tested 2.6.29 +
05f4f678 + the combined patch.  Both look  OK.  Feel free to add a
tested-by or acked-by for "J. Bruce Fields" <bfields@citi.umich.edu> as
appropriate.  Or happy to add a s-o-b and shepherd it along myself if
it's easier....

--b.

diff --git a/fs/nfsd/nfs4recover.c b/fs/nfsd/nfs4recover.c
index 210709c..5275097 100644
--- a/fs/nfsd/nfs4recover.c
+++ b/fs/nfsd/nfs4recover.c
@@ -257,36 +257,6 @@ out:
 }
 
 static int
-nfsd4_remove_clid_file(struct dentry *dir, struct dentry *dentry)
-{
-	int status;
-
-	if (!S_ISREG(dir->d_inode->i_mode)) {
-		printk("nfsd4: non-file found in client recovery directory\n");
-		return -EINVAL;
-	}
-	mutex_lock_nested(&dir->d_inode->i_mutex, I_MUTEX_PARENT);
-	status = vfs_unlink(dir->d_inode, dentry);
-	mutex_unlock(&dir->d_inode->i_mutex);
-	return status;
-}
-
-static int
-nfsd4_clear_clid_dir(struct dentry *dir, struct dentry *dentry)
-{
-	int status;
-
-	/* For now this directory should already be empty, but we empty it of
-	 * any regular files anyway, just in case the directory was created by
-	 * a kernel from the future.... */
-	nfsd4_list_rec_dir(dentry, nfsd4_remove_clid_file);
-	mutex_lock_nested(&dir->d_inode->i_mutex, I_MUTEX_PARENT);
-	status = vfs_rmdir(dir->d_inode, dentry);
-	mutex_unlock(&dir->d_inode->i_mutex);
-	return status;
-}
-
-static int
 nfsd4_unlink_clid_dir(char *name, int namlen)
 {
 	struct dentry *dentry;
@@ -296,18 +266,18 @@ nfsd4_unlink_clid_dir(char *name, int namlen)
 
 	mutex_lock(&rec_dir.dentry->d_inode->i_mutex);
 	dentry = lookup_one_len(name, rec_dir.dentry, namlen);
-	mutex_unlock(&rec_dir.dentry->d_inode->i_mutex);
 	if (IS_ERR(dentry)) {
 		status = PTR_ERR(dentry);
-		return status;
+		goto out_unlock;
 	}
 	status = -ENOENT;
 	if (!dentry->d_inode)
 		goto out;
-
-	status = nfsd4_clear_clid_dir(rec_dir.dentry, dentry);
+	status = vfs_rmdir(rec_dir.dentry->d_inode, dentry);
 out:
 	dput(dentry);
+out_unlock:
+	mutex_unlock(&rec_dir.dentry->d_inode->i_mutex);
 	return status;
 }
 
@@ -350,7 +320,7 @@ purge_old(struct dentry *parent, struct dentry *child)
 	if (nfs4_has_reclaimed_state(child->d_name.name, false))
 		return 0;
 
-	status = nfsd4_clear_clid_dir(parent, child);
+	status = vfs_rmdir(parent->d_inode, child);
 	if (status)
 		printk("failed to remove client recovery directory %s\n",
 				child->d_name.name);

  reply	other threads:[~2009-04-20 19:50 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-19 14:54 Q: NFSD readdir in linux-2.6.28 hooanon05
2009-03-19 15:17 ` David Woodhouse
2009-03-19 15:34   ` hooanon05
2009-03-19 15:51     ` David Woodhouse
2009-04-17  9:32     ` David Woodhouse
2009-04-17 19:32       ` Al Viro
2009-04-17 22:17         ` David Woodhouse
2009-04-17 22:43           ` Al Viro
2009-04-17 22:51             ` David Woodhouse
2009-04-17 22:53             ` Al Viro
2009-04-17 22:55               ` David Woodhouse
2009-04-17 23:23               ` David Woodhouse
2009-04-17 23:37                 ` Al Viro
2009-04-17 23:39                   ` Al Viro
2009-04-18  0:15               ` [PATCH] Fix i_mutex handling in nfsd readdir David Woodhouse
2009-04-18  3:11                 ` hooanon05
2009-04-18 14:25                   ` Al Viro
2009-04-19  7:18                   ` David Woodhouse
2009-04-19 12:27                 ` [PATCH v2] " David Woodhouse
2009-04-19 20:51                   ` J. Bruce Fields
2009-04-20 19:50                     ` J. Bruce Fields [this message]
2009-04-21  0:29                       ` Al Viro
2009-04-21 21:15                         ` J. Bruce Fields
2009-04-21 21:54                           ` Al Viro
2009-05-11 23:16                       ` J. Bruce Fields
2009-04-22  4:41                   ` hooanon05
2009-04-22 19:12                     ` J. Bruce Fields
2009-04-23  6:40                       ` hooanon05
2009-04-23 20:27                         ` J. Bruce Fields
2009-05-05 23:35                           ` J. Bruce Fields
2009-05-06  5:09                             ` hooanon05
2009-05-06 20:20                               ` J. Bruce Fields
2009-05-07  4:38                                 ` hooanon05
2009-05-08 18:47                                   ` J. Bruce Fields
2009-03-19 15:37   ` Q: NFSD readdir in linux-2.6.28 Matthew Wilcox
2009-03-19 15:45     ` hooanon05
2009-03-19 16:01     ` David Woodhouse
2009-04-16 21:45   ` J. Bruce Fields
2009-04-17  4:13     ` hooanon05

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=20090420195008.GE1823@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=dwmw2@infradead.org \
    --cc=hch@infradead.org \
    --cc=hooanon05@yahoo.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@ZenIV.linux.org.uk \
    /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.