From: Ram Pai <linuxram@us.ibm.com>
To: Guo Chao <yan@linux.vnet.ibm.com>
Cc: Ram Pai <linuxram@us.ibm.com>,
"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 15:27:32 +0800 [thread overview]
Message-ID: <20120910072732.GL2387@ram-ThinkPad-T61> (raw)
In-Reply-To: <20120910063724.GA6272@yanx>
On Mon, Sep 10, 2012 at 02:37:24PM +0800, Guo Chao wrote:
> 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.
I think the code that checks if the new dentry or the old dentry is a
mount point can be safely removed. It does not serve any purpose AFAICT.
RP
next prev parent reply other threads:[~2012-09-10 7:28 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
2012-09-10 7:27 ` Ram Pai [this message]
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=20120910072732.GL2387@ram-ThinkPad-T61 \
--to=linuxram@us.ibm.com \
--cc=bfields@fieldses.org \
--cc=bfields@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=yan@linux.vnet.ibm.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).