linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: trond.myklebust@netapp.com
Cc: linux-nfs@vger.kernel.org
Subject: [PATCH 0/8] nfs: ensure that sillyrenames run to completion (try #2)
Date: Wed, 15 Sep 2010 09:23:53 -0400	[thread overview]
Message-ID: <1284557041-4375-1-git-send-email-jlayton@redhat.com> (raw)

This patchset is pretty much identical to the one that I sent last week.
It has one minor fix -- I fixed it to use nfs_free_fattr instead of
kfree in nfs_async_rename_release. I also cleaned up the comments a bit.

We had a bug report recently where someone was complaining about
silly-renamed files being left around:

https://bugzilla.redhat.com/show_bug.cgi?id=511901

...they attached a reproducer to the bug which involves a
pthreads-based program killing a child thread that's unlinking and
closing a file.

The unlink triggers a sillyrename (since the file is still open). The
parent kills the child thread and if timed just right, the child thread
will be killed after the RENAME call is issued but before the reply is
processed. The file will end up renamed on the server, but the client
won't be aware of it and won't unlink it during dentry_iput.

This patchset is intended to prevent this from happening by having
nfs_sillyrename use an asynchronous rename call and simply wait for the
call to complete in TASK_KILLABLE sleep before proceeding. If the task
is killed while the rename RPC is on the wire, it'll still run to
completion even though the thread that initiated it was killed off.

To facilitate this, the set first changes all of the existing rename
calls to use standardized argument and response containers. The
nfs_sillyrename call is then moved to unlink.c (where the rest of the
sillyrename code lives), and then is converted to use an asynchronous
RPC call to handle the rename.

I've tested this by running the reproducer in the above bug report
in a loop for several hours and never ended up with a leftover .nfs*
file.

I'd like to see this in 2.6.37 if possible.

Jeff Layton (8):
  nfs: eliminate nfs3_renameargs
  nfs: convert nfs_renameargs to use qstr structs
  nfs: eliminate nfs4_rename_arg
  nfs: standardize the rename response container
  nfs: move nfs_sillyrename to unlink.c
  nfs: add a rename_setup nfs_rpc_op for async renames
  nfs: add rename_done nfs_rpc_op
  nfs: make sillyrename an async operation

 fs/nfs/dir.c            |   70 -------------
 fs/nfs/nfs2xdr.c        |    8 +-
 fs/nfs/nfs3proc.c       |   62 +++++++++---
 fs/nfs/nfs3xdr.c        |   16 ++--
 fs/nfs/nfs4proc.c       |   43 ++++++++-
 fs/nfs/nfs4xdr.c        |    4 +-
 fs/nfs/proc.c           |   34 +++++-
 fs/nfs/unlink.c         |  253 ++++++++++++++++++++++++++++++++++++++++++++++-
 include/linux/nfs_fs.h  |    2 +-
 include/linux/nfs_xdr.h |   64 +++++--------
 10 files changed, 406 insertions(+), 150 deletions(-)


             reply	other threads:[~2010-09-15 13:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-15 13:23 Jeff Layton [this message]
2010-09-15 13:23 ` [PATCH 1/8] nfs: eliminate nfs3_renameargs Jeff Layton
2010-09-15 13:23 ` [PATCH 2/8] nfs: convert nfs_renameargs to use qstr structs Jeff Layton
2010-09-15 13:23 ` [PATCH 3/8] nfs: eliminate nfs4_rename_arg Jeff Layton
2010-09-15 15:26   ` Chuck Lever
2010-09-15 15:34     ` Jeff Layton
2010-09-15 16:45     ` Trond Myklebust
2010-09-15 16:50       ` Chuck Lever
2010-09-15 13:23 ` [PATCH 4/8] nfs: standardize the rename response container Jeff Layton
2010-09-15 15:29   ` Chuck Lever
2010-09-15 15:38     ` Jeff Layton
2010-09-15 13:23 ` [PATCH 5/8] nfs: move nfs_sillyrename to unlink.c Jeff Layton
2010-09-15 13:23 ` [PATCH 6/8] nfs: add a rename_setup nfs_rpc_op for async renames Jeff Layton
2010-09-15 15:39   ` Chuck Lever
2010-09-15 17:23     ` Jeff Layton
2010-09-15 13:24 ` [PATCH 7/8] nfs: add rename_done nfs_rpc_op Jeff Layton
2010-09-15 13:24 ` [PATCH 8/8] nfs: make sillyrename an async operation Jeff Layton
2010-09-15 13:37   ` Jeff Layton
2010-09-15 15:04     ` Jeff Layton

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=1284557041-4375-1-git-send-email-jlayton@redhat.com \
    --to=jlayton@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@netapp.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).