From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: How to handle non-local renames? Date: Thu, 28 Sep 2006 12:21:42 +0100 Message-ID: <20060928112142.GB29920@ftp.linux.org.uk> References: <1158597517.6297.10.camel@lade.trondhjem.org> <1158883241.5535.7.camel@lade.trondhjem.org> <20060928100223.GY29920@ftp.linux.org.uk> <20060928102748.GA29920@ftp.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: trond.myklebust@fys.uio.no, dhowells@redhat.com, linux-fsdevel@vger.kernel.org Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:22689 "EHLO ZenIV.linux.org.uk") by vger.kernel.org with ESMTP id S1161069AbWI1LVp (ORCPT ); Thu, 28 Sep 2006 07:21:45 -0400 To: Miklos Szeredi Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Sep 28, 2006 at 12:53:01PM +0200, Miklos Szeredi wrote: > > > > Simpler: if alias and our dentry share the parent, it's locked and > > > > we can rename without s_vfs_rename_mutex. If they do not, walk the > > > > tree under alias, unhash all non-directories and kill all directories. > > > > > > What do you mean by "killing directories"? Unhashing the inode? > > > > > > Are these OK, without holding i_mutex on alias and descendents? > > > > Only dcache locking is needed for unhashing dentries (which is what > > we do to non-directories). For directories, we should silently > > unhash inodes and make sure that all future operations on those inodes > > would fail. Up to filesystem how you do that. Additionally, make > > sure that revalidation fails on those suckers. > > OK, what about operations currently in progress on those directories > and files? Is there no way these can cause trouble? We need variants of d_move() and d_rehash() that do not take dcache_lock, so that such fs would use them under dcache_lock, then check if parent is dead and do the same kind of unhashing/killing if it is. I.e. pretend that we'd won the race and killer lookup came later.