Re: [RFC][PATCH 1/8] namespace: use global namespace semaphore

[raven@themaw.net]

On Fri, 3 Jun 2005, Mike Waychison wrote:

> Ian Kent wrote:
> > On Wed, 1 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.
> 
> Just to make sure we are all on the same page:

I think we're going to confuse the hell out of Miklos here.

Each talking about fundamentally different automount implementations using 
similar approaches.

Sorry Miklos.

> 
> If you use follow_link logic on a _directory_, it becomes impossible for
> userspace to open(2) that given directory.  However, if the kernel knows all,
> and can do an open(2) on it, and pass that to the userspace autofs handler.

Indeed, analysing the implications of open(2) is where I'm upto at the 
moment. So I'm not quite on the same page here just yet.

> 
> Now, the userspace autofs bits can fchdir(fd) on that fd, and the kernel will
> happily change current's cwd to that magic directory.
> 
> Then, with the cwd set to that magic directory, userspace can do a 'mount
> --move /tmp/temp_mountpoint .', which moves the filesystem mounted at
> /tmp/temp_mountpoint on top of the magic directory.
> 
> Now, the magic directory is covered up, and ->follow_link will never be called
> again because the VFS will directly walk over it during a follow_down loop.
> 
> Care has to be taken to ensure that multiple processes that 
> ->follow_link get put on the same wait_queue waiting for the mount to occur.
> 
> Take a look at fs/autofsng/request.c for an implementation of this.
> 
> > 
> > 
> > > > >So the result is two sibling mounts: the original autofs and the
> > > > >actual filesystem.  But subsequent lookups will see the later mount
> > > > >only, since it's placed earlier on the hash chain, and lookup_mnt()
> > > > >will
> > > > >always return that.
> > > >
> > > >Don't know that I care about that to much.
> > > >It yields correct behaviour except for expires.
> > > >In this case the expire can only determine timeouts relative to busyness
> > > >as walks scoot over the top. Indirect mounts (the other class of autofs
> > > >mounts) update usage on every access (or walk).
> > >
> > >Yes, but with direct mounts you cannot use this to check busyness.
> > 
> > 
> > That's not entirely right but your point is well made.
> > 
> > 
> > >But there's ->mnt_expiry_mark, I think you can use that to check if
> > >mount was recently walked over.
> > 
> > 
> > I'll check that.
> > 
> > I'll probably be reluctant to go that way simply because I want to backport
> > this to 2.4. But maybe that will become secondary as work progresses.
> > 
> > Never the less it may well provide the extra functionality I need.
> > 
> 
> The one problem with mnt_expiry_mark is that it isn't recursive, so if you
> want to expire a tree of mountpoints (like autofs4 currently does), you have
> to feed it steroids:
> 
> http://marc.theaimsgroup.com/?l=linux-fsdevel&m=109875168418269&w=2
> http://marc.theaimsgroup.com/?l=linux-kernel&m=109875147222911&w=2
> http://marc.theaimsgroup.com/?l=linux-fsdevel&m=109871584122188&w=2
> 
> > 
> > >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.
> > 
> > Ian
> > 
>