[9fans] [RFC] sysremove()/sysmount() race

[9fans] [RFC] sysremove()/sysmount() race

[Alexander Viro]

	Folks, AFAICS there is a window during mount() when you
can remove() the mountpoint. There's no locking between namec()
and cmount(), so as far as I can see there's nothing to stop 
sysremove() from happening in that window. Since nothing is mounted
yet, we end up removing the mountpoint (after mount we would attempt
to remove the root of mounted fs).
	I'm not saying that it's a bug, but... how well does userland
deal with that? AFAICS kernel should be OK...
						Cheers,
							Al
PS: ssh'd from a Linux box that runs 2.4.2+namespaces patch. 2 users,
5 different namespaces right now... ;-) Off to porting libfs...

Re: [9fans] [RFC] sysremove()/sysmount() race

[Russ Cox]

I don't see what the problem is.  Namec gets you a
chan, either pre- or post-mount.  If you get in
before the remove, the mount succeeds but attempts
to access the mount point fail.  If you get in after
the remove, the mount itself fails.  

More generally, I don't see how this is any different
than some other user (on a different machine entirely)
removing the mount point at the same time you do a mount.
You get exactly the same behavior, which means the kernel
is probably doing the right thing.

Backing up even more, it's not really any different
than doing chmod 0 on some directory -- processes with
a working directory deeper than that will continue to
access files, but you won't be able to evaluate any 
rooted names that go through that directory.

In all cases, there's no way to prevent it from happening,
and the behavior is entirely understandable.

Russ