lkml.org 
[lkml]   [2009]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 00/17] [RFC] AFS: Implement OpenAFS pioctls(version)s
On Wed, Jun 17, 2009 at 07:03:43PM +0100, David Howells wrote:
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> > What _I_ mean is that THIS IS IMPOSSIBLE TO DO FROM USER SPACE!
> >
> > Try it. Not doable. User space simply doesn't know enough, and has
> > fundamental races with mount/umount.
>
> Ummm... I'm not sure I completely agree. If you've managed to open, say,
> "/afs", where's the race with mount/umount? You've got a file descriptor you
> can use as a handle. Yes, you have to check that it's actually an inode of
> your fs, but that's not exactly difficult, and that's not going to change just
> because someone unmounts it or mounts over it whilst you've got it open.

I believe Linus is arguing that in the general case, it's impossible
to open the mountpoint of an arbitrarily mounted filesystem. David,
you're arguing that by convention the afs root is *always* in /afs,
and that the afs utilities will always simply open "/afs", and thus
it's not hard to find the mount point, since afs works by having a
single top-level static mount point --- and AFS hides the
lookup of what volume server you might need to go to when you open
/afs/athena.mit.edu/user/t/y/tytso versus /afs/andrew.cmu.edu/usr/shadow.

There are no magic "automounts" such that OS won't know that
user.tytso AFS Volume in the athena.mit.edu AFS cell is at
/afs/athena.mit.edu/user/t/y/tytso, so the only "mountpoint" that
exists as far as AFS is concerned is at /afs --- and that in the AFS
world, it's essentially a universal convention that AFS pathnames
begin with "/afs", and so the AFS filesystem will always be mounted in /afs.

- Ted


\
 
 \ /
  Last update: 2009-06-17 20:33    [W:0.203 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site