From: Guo Chao <yan@linux.vnet.ibm.com>
To: Ram Pai <linuxram@us.ibm.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
"J. Bruce Fields" <bfields@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [RFC PATCH 05/13] vfs: take i_mutex on renamed file
Date: Mon, 10 Sep 2012 14:37:24 +0800 [thread overview]
Message-ID: <20120910063724.GA6272@yanx> (raw)
In-Reply-To: <20120910051037.GA2466@ram-ThinkPad-T61>
On Mon, Sep 10, 2012 at 01:10:37PM +0800, Ram Pai wrote:
> On Mon, Sep 10, 2012 at 10:40:51AM +0800, Guo Chao wrote:
> >
> > Hard to say whether it's a bug or what's problems of being able to rename
> > mountpoint.
>
> 'man 2 rename' says it is ok to rename a directory that is already
> mounted.
>
> EBUSY The rename fails because oldpath or newpath is a directory that is
> in use by some process (perhaps as current working directory, or as root
> directory, or beacuse it was open for reading) or is in use by the
> system (for example as mount point), while the system considers this an
> error. (Note that there is no requirement to return EBUSY in such
> cases-- there is nothing wrong with doing the rename anyway -- but is
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> allowed to return EBUSY if the system cannot otherwise handle such
> situations)
>
> RP
Erhh, good point.
However, current implementation seems to return EBUSY unconditionally,
instead of considering whether it can handle this situation. It can be
descripted as 'it may return EBUSY or not, depends on whether you are
luck enough to rush into the race'.
This seems still conform to the statement in the manual, in a weird way
though.
next prev parent reply other threads:[~2012-09-10 6:37 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-05 20:55 [RFC PATCH 00/13] Implement NFSv4 delegations, take 4 J. Bruce Fields
2012-09-05 20:55 ` [RFC PATCH 01/13] gfs2: Get rid of I_MUTEX_QUOTA usage J. Bruce Fields
2012-09-05 20:59 ` J. Bruce Fields
2012-09-06 14:27 ` Steven Whitehouse
2012-09-06 17:08 ` J. Bruce Fields
2012-09-05 20:55 ` [RFC PATCH 02/13] vfs: pull ext4's double-i_mutex-locking into common code J. Bruce Fields
2012-09-06 2:53 ` Guo Chao
2012-09-06 13:49 ` J. Bruce Fields
2012-09-05 20:55 ` [RFC PATCH 03/13] vfs: don't use PARENT/CHILD lock classes for non-directories J. Bruce Fields
2012-09-05 20:55 ` [RFC PATCH 04/13] vfs: rename I_MUTEX_QUOTA now that it's not used for quotas J. Bruce Fields
2012-09-05 20:55 ` [RFC PATCH 05/13] vfs: take i_mutex on renamed file J. Bruce Fields
2012-09-06 3:05 ` Guo Chao
2012-09-06 17:51 ` J. Bruce Fields
2012-09-07 2:27 ` Guo Chao
2012-09-07 21:39 ` J. Bruce Fields
2012-09-10 2:40 ` Guo Chao
2012-09-10 5:10 ` Ram Pai
2012-09-10 6:37 ` Guo Chao [this message]
2012-09-10 7:27 ` Ram Pai
2013-02-14 2:01 ` Al Viro
2012-09-10 14:35 ` J. Bruce Fields
2012-09-05 20:55 ` [RFC PATCH 06/13] locks: introduce new FL_DELEG lock flag J. Bruce Fields
2012-09-05 20:55 ` [RFC PATCH 07/13] locks: implement delegations J. Bruce Fields
2012-09-05 20:55 ` [RFC PATCH 08/13] namei: minor vfs_unlink cleanup J. Bruce Fields
2012-09-05 20:55 ` [RFC PATCH 09/13] locks: break delegations on unlink J. Bruce Fields
2012-09-05 20:55 ` [RFC PATCH 10/13] locks: helper functions for delegation breaking J. Bruce Fields
2012-09-05 20:55 ` [RFC PATCH 11/13] locks: break delegations on rename J. Bruce Fields
2012-09-05 20:55 ` [RFC PATCH 12/13] locks: break delegations on link J. Bruce Fields
2012-09-05 21:02 ` J. Bruce Fields
2012-09-06 11:01 ` Jeff Layton
2012-09-06 13:33 ` J. Bruce Fields
2012-09-05 20:55 ` [RFC PATCH 13/13] locks: break delegations on any attribute modification J. Bruce Fields
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=20120910063724.GA6272@yanx \
--to=yan@linux.vnet.ibm.com \
--cc=bfields@fieldses.org \
--cc=bfields@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--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 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).