Re: symlink_prefix

[Edgar Toernig <froese@gmx.de>]

Alexander Viro wrote:
> 
> On Thu, 7 Jun 2001, Edgar Toernig wrote:
> 
> > Alexander Viro wrote:
> > >         ...
> > >         dir = open("/usr/local", O_DIRECTORY);
> > >         /* error handling */
> > >         new_mount(dir, MNT_SET, fs_fd); /* closes dir and fs_fd */
> >
> > Do you really want to start using fds instead of strings for tree
> > modifying commands (link, unlink, symlink, rename, mount and umount)?
> > Even if it were possible in the new_mount case it wouldn't have the
> > atomic lookup+act nature of the old mount.  And then, _I_ would
> > prefer a uniform interface for tree management commands - strings.
> 
> You have exactly the same atomicity warranties. That is to say, none.
> Mountpoint can be renamed between the lookup and mounting.

Ok.  I thought, mounting is an atomic operation (though normally not
required).  Hmm... but looking at your last batch of VFS patches sent
to lkml you consider mount a more used call in the future ;-)  Maybe
it would be better to have some more strict rules for mount if ie each
login performs a dozen of them...

> Moreover, even after mount(2) you can rename() parent of mountpoint. On
> all Unices I've seen (well, aside of v7 which didn't have rename(2)).
> So if you rely on anything of that kind - you are screwed. Portably
> screwed, at that.

I thought more about a rename of ie "/usr/local" between the open and
the new_mount call.  I guess, an unlink("/usr/local") after the open
will let the new_mount fail.  Btw, what happens in this case of two
concurrent mounts?

	fd1=open("/foo")
	fd2=open("/foo")
	new_mount(fd1...)
	new_mount(fd2...)	// or vice versa, first fd2 then fd1

>[...] but even if your argument makes sense, it only makes sense for
> "dir" argument. "device" is nothing but a filesystem-specific option.

Sure.  I only meant the "dir" argument.

Maybe I've just an uneasy feeling about such a change because it exposes
and depends on internal implementation details of the kernel (the dcache).
On other systems it's normally not possible to associate a unique name
with a file descriptor.  Newer Linux versions may support this for
directories due to the dcache (not sure if this is really always the case).
And this calling convention for new_mount would be the first one that
makes this visible in userspace.  And it would depend on this feature.
This may limit future changes of the kernel VFS implementation (maybe
someone really adds some kind of hardlinked directories or something
else that makes it impossible to get a unique name for a dir fd).

Ciao, ET.