From mboxrd@z Thu Jan 1 00:00:00 1970 From: raven@themaw.net Subject: Re: [RFC][PATCH 1/8] namespace: use global namespace semaphore Date: Sat, 4 Jun 2005 12:13:00 +0800 (WST) Message-ID: References: <429BD8B7.7070906@waychison.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: mike@waychison.com, linux-fsdevel@vger.kernel.org, jamie@shareable.org, viro@parcelfarce.linux.theplanet.co.uk Return-path: Received: from wombat.indigo.net.au ([202.0.185.19]:37647 "EHLO wombat.indigo.net.au") by vger.kernel.org with ESMTP id S261232AbVFDEXg (ORCPT ); Sat, 4 Jun 2005 00:23:36 -0400 To: Miklos Szeredi In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, 3 Jun 2005, Miklos Szeredi wrote: > > > > > > > > > > This way the autofs mount won't be followed by the mount program, > > > > > since looking up '.' does not follow mounts. > > > > > > > > But a path walk must be carried out in order to set pwd (or > > > > chroot), at which time the mount is carried out and remains busy > > > > due to the reference that is held. > > > > > > Huh? Path walk of '.' will do nothing. It does not follow mounts or > > > anything. > > > > Does "chdir ." make sense. Looks a bit like a noop to me. Surely if > > your current working directory is "." you've had to set it with a > > provided path at some point. > > OK, sorry, I misunderstood you. > > But still I don't see why it is a problem if you have a reference to > the mountpoint dentry/vfsmount. You already have a reference with the > mounted autofs, so adding another reference by opening a file, and > another by changing cwd to it won't change anything at all. I think we`ve lost track of what we originally started discussing here. I think we started discussing why I needed the nameidata struct to be upto date when the follow link method was called, it simply isn't when a mount is followed at the end of the do_lookup call in link_path_walk. > > > > So for direct mounts, the sibling mount (as opposed to the overmount) > > > has the advantage of not having to do ugly recursion checking hacks in > > > autofs. > > > > I've found that all I really need to do is check that the follow_mount is > > successful and respond accordingly. > > I don't see how that would work. Seems to work fine so far. > > Don't you have to somehow special-case the mount program to allow that > to succeed in path lookup, but make all other lookups block until the > mount is finished? I haven't found that to be the case. There are a couple of mechanisms for this. First is a in kernel module waitq for daemon notification that has been well tested over time. I've done quite a bit of work on the interaction between expire events and lookups. There are still a couple of patches I need to submit but it's getting there. Second the user space daemon is implemented as an FSM which implies a considerable amount of serialisation wrt kernel communication through the pipe. Ian