Jeff, here's a subfs blocker for you. 

Hrm. The steps to reproduce seem straightforward enough, but I can't seem to.

My usb stick is named "JEFFM-KEY."

I plug it in, and /media/JEFFM-KEY appears as it should.

I cd into a subdirectory of that, and ls. I wait a few moments, unplug the
stick, and try again. I get "No medium found" if I'm in the subfs root, or just
an empty listing if I'm in a subdirectory.

The mount point is removed. When I re-insert the stick, the mount point is
created again. Of course, since the directory went away, I'm not longer in
"that" directory, so the remount won't occur until I reassess the pathname.

I don't see anything about it getting mounted over /.

Is there something I'm missing in the reproduction?

Try this:

- insert usbstick (wait for mount )
- cd /media/JEFFM-KEY
- remove usbstick
- reinsert usbstick
- ls (in /media/JEFFM-KEY)
- cat /proc/mounts (a mount to '/' for the usbstick )

If this not work, play around with ls befor remove stick or befor reinsert, but 
with the way about I can reproduce this here permanently.

Ok, I can see it appearing in /proc/mounts, though it's not actually obscuring
the real / mount. Still, shouldn't be happening.

note: in this case (mount to /) the submountd hangs up and try permanently to 
get '/' and access the harddisk every second. I maybe also take a look at 
submountd to prevent this, imo the real problem is the kernel modul which call 
the submountd.

Ok, I understand what's happening here.

When the filesystem is umounted, and the process is chdir'd into the directory,
the tree is detached from the main filesystem hierarchy, creating an isolated
namespace. The path to the "old" mount point no longer exists, even if the
pathname in the filesystem itself does. This is similar to the following:

mkdir foo
cd foo
rmdir ../foo

I think a point of confusion is that bash's built-in 'pwd' command plays tricks
and remembers the pathname internally. That's why "cd ." works. Since the kernel
doesn't play such tricks, a chdir(2) call will not end up with the same results.

jeffm@speedracer:/media/JEFFM-KEY> /bin/pwd
/media/JEFFM-KEY
<remove stick>
jeffm@speedracer:/media/JEFFM-KEY> /bin/pwd
/

The second pwd shows that the process thinks it's in the root of an entirely
separate namespace. The processes "root" is actually still the root of the
"real" namespace. Unfortunately, there is no way to make the connection between
the two namespaces, since that link was severed when the namespace was detached.

I can detect this condition in the kernel, but since I can't re-establish the
pathname, there is no way of mounting the filesystem at the correct mount point.

I can cache it when there is a valid lookup -- but this violates one of the
tenets of Linux filesystem design: filesystem code shouldn't care where it's
mounted. I would very much not like to do this.

I think the correct answer is to detect the condition and fail the mount with
-ENOENT, the same as if a user tried creating a new object under the deleted
directory in the first example cited. The user can access the full pathname and
cause the mount to succeed.

Created attachment 48528 [details]
fix for subfs attempting to mount devices in detached namespaces

This patch fixes subfs so that it doesn't attempt to mount filesystems in a
detached namespace.

It returns -ENOENT, similar to how the following condition would be handled:

speedracer:/mnt # mkdir foo
speedracer:/mnt # cd foo
speedracer:/mnt/foo # rmdir ../foo
speedracer:/mnt/foo # mount /dev/sdf1 .
mount: No such file or directory
speedracer:/mnt/foo #

HAs this fix been committed to our kernel?  Can this bug get closed?

Committed.