Re: [PATCH 12/18] shared mount handling: bind and rbind

From: Rob Landley
Date: Wed Nov 16 2005 - 03:41:51 EST

On Tuesday 15 November 2005 21:53, Linus Torvalds wrote:
> So if you mount over '/', it won't actually do what you think it does:
> because when you open "/", it will continue to open the _old_ "/". Exactly
> the same way that mounting over somebody's cwd won't do what you think it
> does - because the root and the cwd have been looked-up earlier and are
> cached with the process.

So does mounting over / actually accomplish anything? Or is it sort of an
undermount instead of an overmount, resulting in a mounted but inaccessible
filesystem? (In theory, fork() would copy the current cached value of "/",
and all absolute path lookups are really sort of relative paths from the
cached "/"...)

I ask because I'm trying to figure out what switch_root's "mount --move . /"
accomplishes, other than making /proc/mounts look right. If we just did the
chroot(".") it'd be functionally the same, and slightly smaller (which
busybox cares about).

I'm also remembering that while playing around with stuff in a PID 1 shell
under UML (trying to figure out how to implement pivot_root), I mounted
something directly on / (which was a NOP) and then umount was also a NOP
(presumably because it was trying to umount rootfs), meaning I had a mount
that had simply _leaked_. It still showed up in /proc/mounts, but was
totally inaccessable and couldn't be removed either.

I guess that's a "don't do that then".

> This is why we have "pivot_root()" and "chroot()", which can both be used
> to do what you want to do. You mount the new root somewhere else, and then
> you chroot (or pivot-root) to it. And THEN you do 'chdir("/")' to move the
> cwd into the new root too (and only at that point have you "lost" the old
> root - although you can actually get it back if you have some file
> descriptor open to it).

So all chroot(2) really does is reset the "/" reference?

In the specific case of "mount --move . /" || chroot ("."), I don't see why we
need a chdir afterwards, because cwd points to the correct filesystem. (In
fact, for a moment there between the mount move and the chroot it's the
_only_ reference we have to this filesystem.)

Perhaps ".." isn't correct unless we chdir again...?

> Linus

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at