From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [some sanity for a change] possible design issues for hybrids Date: Thu, 26 Aug 2004 19:46:41 -0700 (PDT) Message-ID: References: <20040826203228.GZ21964@parcelfarce.linux.theplanet.co.uk> <20040826212853.GA21964@parcelfarce.linux.theplanet.co.uk> <20040826223625.GB21964@parcelfarce.linux.theplanet.co.uk> <20040826225308.GC21964@parcelfarce.linux.theplanet.co.uk> <20040826234048.GD21964@parcelfarce.linux.theplanet.co.uk> <20040827010147.GE21964@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Denis Vlasenko , Rik van Riel , Diego Calleja , jamie@shareable.org, christophe@saout.de, christer@weinigel.se, spam@tnonline.net, akpm@osdl.org, wichert@wiggy.net, jra@samba.org, reiser@namesys.com, hch@lst.de, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, flx@namesys.com, reiserfs-list@namesys.com Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com To: viro@parcelfarce.linux.theplanet.co.uk In-Reply-To: <20040827010147.GE21964@parcelfarce.linux.theplanet.co.uk> List-Id: linux-fsdevel.vger.kernel.org On Fri, 27 Aug 2004 viro@parcelfarce.linux.theplanet.co.uk wrote: > > Hmm... IOW, you are suggesting to use normal trigger for lookup_mnt() and > then have extra check in lookup_mnt() failure exit. Yes. That should be an _extremely_ rare failure case anyway, unless people start using namespaces more. > Freeing these guys will not be fun. I agree. I frankly have no idea how to do it. I think we need to keep them around for as long as the dentry lifetime, I suspect. That would likely imply that the vfsmount can't increase the dentry refcount - and we'd have some special code in dentry_iput() or something to get rid of them. > Situation with unlink(): we need to (a) check that all vfsmounts over > given point are "hybrid" ones (locking is not a problem at that point) > and (b) after successful operation (unlink() and rename() alike, AFAICS) > we want to go and kill everything under the victim dentry. *That* > can get very ugly, since fs could be mounted in a lot of places and/or > in a lot of namespaces. It _might_ be acceptable to just do the normal shrink_dentry thing, and then return EBUSY if somebody is still there. > Locking rules for attaching might need adjustment (the logics with ->i_sem > is that we want !d_mountpoint() stay true around call of ->unlink(), > ->rmdir() and ->rename() That should be ok. Since we'd only do the d_mount stuff on a "->lookup()", and since the lookup will take ->i_sem anyway, we should be fine, no? > One thing that looks like a bad interface: we get forcible "use same > dentry for file and directory" with that design. Hmm.. Wouldn't the "directory" dentry always be the fake-mountpoint root one? So we'd always have two dentries, although they are tied together pretty tightly.. Linus