Return-Path: linux-nfs-owner@vger.kernel.org Received: from e28smtp09.in.ibm.com ([122.248.162.9]:43008 "EHLO e28smtp09.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750706Ab2IJGhh (ORCPT ); Mon, 10 Sep 2012 02:37:37 -0400 Received: from /spool/local by e28smtp09.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 10 Sep 2012 12:07:33 +0530 Date: Mon, 10 Sep 2012 14:37:24 +0800 From: Guo Chao To: Ram Pai Cc: "J. Bruce Fields" , "J. Bruce Fields" , Al Viro , linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [RFC PATCH 05/13] vfs: take i_mutex on renamed file Message-ID: <20120910063724.GA6272@yanx> References: <1346878524-10585-1-git-send-email-bfields@redhat.com> <1346878524-10585-6-git-send-email-bfields@redhat.com> <20120906030526.GB6679@yanx> <20120906175118.GC21736@fieldses.org> <20120907022705.GA20453@yanx> <20120907213901.GA5927@fieldses.org> <20120910024051.GA10405@yanx> <20120910051037.GA2466@ram-ThinkPad-T61> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20120910051037.GA2466@ram-ThinkPad-T61> Sender: linux-nfs-owner@vger.kernel.org List-ID: 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.