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

[raven@themaw.net]

On Sat, 4 Jun 2005, Miklos Szeredi wrote:

> > What interface?
> > 
> > I'm not aware of any clearly defined API for access to in kernel functions 
> > for the VFS except for the various operations methods. Unfortuneatly, any 
> > struct that is passed to them should be largely imutable as well. Which 
> > ultimeatly covers the structs we are talking about here.
> 
> You are right that it's not an explicitly defined API.  However the
> only _truly_ exported part of the mount api is mntget/mntput.  You'll
> notice, that only closely related code (path lookup, dentry cache)
> will ever touch anything in struct vfsmount, and even those only in a
> very few places.
> 
> So struct vfsmount is _not_ part of the API, and no unrelated code (in
> or out of the kernel) should touch any part of it.
> 
> > All I see is people taking the oppertunity to stop exporting functions 
> > without consideration to what should be considered part of an API.
> > 
> > Some companies do this really well to foster development.
> 
> And generally using things which are not really part of an API just
> results in messy and buggy code.  So even if it makes development
> easier, it's not worth it on the long run.

OK. Sorry to go on about this but it's is just my little hobby horse.

> 
> > Yes. That would be the case except there's a reference held to the 
> > vfsmount in the struct path prior to point at which follow_link is called, 
> > which I don't think can be obtained.
> > 
> > In any case I'll find a way to work around it.
> 
> I don't see why you'd need to work around anything.  Following pseudo
> code should work perfectly fine:
> 
> int autofs_follow_link(struct dentry *dentry, struct nameidata *nd)
> {
> 	if (!is_mount_in_progress(dentry))
> 		send_trigger_to_userspace(dentry)
> 
> 	wait_event(mountpoint_waitq(dentry), !is_mount_in_progress(dentry));
> 	while(follow_down(&nd->mnt, &nd->dentry));
> 	return 0;
> }

Indeed, that's pretty much what I have.

And yes I partially missed (ignored) the fact that the follow down should 
do the trick because I believe that there is a follow_down (follow_mount 
actually) that will cause reference to a vfsmount (not accessible in 
follow_link) prior to the follow_link call that, at least in one case, 
is not put. I believe this is held in a struct path (next) local variable. 
For a normal link nd->mnt and next.mnt would be the same. But maybe I'm 
mistaken.

This is what I mean when I say there appears to be an assumption that a 
mount is not followed immediately before the follow_link call in 
link_path_walk.

Ian