From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ram Pai Subject: Re: [PATCH 12/18] shared mount handling: bind and rbind Date: Wed, 09 Nov 2005 10:44:09 -0800 Message-ID: <1131561849.5400.384.camel@localhost> References: <1131464926.5400.234.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Al Viro , torvalds@osdl.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Return-path: To: Miklos Szeredi In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, 2005-11-08 at 07:55, Miklos Szeredi wrote: > > No. As explained in the same earlier threads; without this change the > > behavior of shared-subtrees leads to inconsistency and confusion in some > > scenarios. > > > > Under the premise that no application should depend on this behavior > > (most-recent-mount-visible v/s top-most-mount-visible), > > The strongest argument against was that > > mount foo .; umount . > > would no longer be a no-op. It is a no-op even now. Try it. What you meant was something like this is no-op now? P1: cd /tmp1 P2: mount --bind /var /tmp1 P1: mount --bind /bin . P1: umount . Yes this will not be a noop with my changes. However this behavior is not documented to be a no-op anywhere. right? And 'umount .' really doen't make sense. What does it mean? umount the current mount? or umount of the mount that is mounted on this dentry? My changes just changes one behavior and that is: If multiple mounts are mounted on the same combination the later mounts are obscured by the preceeding mounts. Earlier it was opposite behavior. My biggest complaint about the earlier behavior was that the later mounts obscured not only the earlier mounts on the tuple, but also obscured all the mounts that got stacked on top of the earlier . It seemed totally unnatural, and confusing with shared-subtree. > > Al Viro permitted this change. And this is certainly the right > > behavior. > > Which is a contradiction in term, since you are saying that > applications _do_ depend on it. no. I said application _should_not_ depend on it, because it is a undefined semantics. Sorry I was out yesterday and could reply earlier. RP > > Miklos