From: Al Viro <viro@ZenIV.linux.org.uk>
To: Ram Pai <linuxram@us.ibm.com>
Cc: Guo Chao <yan@linux.vnet.ibm.com>,
"J. Bruce Fields" <bfields@fieldses.org>,
"J. Bruce Fields" <bfields@redhat.com>,
linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [RFC PATCH 05/13] vfs: take i_mutex on renamed file
Date: Thu, 14 Feb 2013 02:01:54 +0000 [thread overview]
Message-ID: <20130214020154.GA17947@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20120910072732.GL2387@ram-ThinkPad-T61>
On Mon, Sep 10, 2012 at 03:27:32PM +0800, Ram Pai wrote:
> > 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.
Yes, it does. It's a _very_ traditional behaviour, on a lot of Unices,
and changing it can screw all kinds of scripts. Worse yet, screw them
in rarely hit cases.
BTW, what do you expect to happen when the target is a mountpoint? Suppose
the mountpoint is a directory that happens to be empty; you are asking to
rename another directory over it...
Anyway, userland API stability considerations are sufficient to NAK any
such change. Sorry.
next prev parent reply other threads:[~2013-02-14 2:02 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
[not found] ` <1346878524-10585-1-git-send-email-bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-09-05 20:55 ` [RFC PATCH 01/13] gfs2: Get rid of I_MUTEX_QUOTA usage J. Bruce Fields
[not found] ` <1346878524-10585-2-git-send-email-bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-09-05 20:59 ` J. Bruce Fields
[not found] ` <20120905205920.GA10724-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
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 05/13] vfs: take i_mutex on renamed file J. Bruce Fields
[not found] ` <1346878524-10585-6-git-send-email-bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-09-06 3:05 ` Guo Chao
2012-09-06 17:51 ` J. Bruce Fields
[not found] ` <20120906175118.GC21736-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2012-09-07 2:27 ` Guo Chao
2012-09-07 21:39 ` J. Bruce Fields
[not found] ` <20120907213901.GA5927-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
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
2013-02-14 2:01 ` Al Viro [this message]
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 08/13] namei: minor vfs_unlink cleanup 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 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 07/13] locks: implement delegations 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 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
[not found] ` <20120906070122.58c21013-4QP7MXygkU+dMjc06nkz3ljfA9RmPOcC@public.gmane.org>
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=20130214020154.GA17947@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--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=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).