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

Rob Landley
2005-11-16T03:30:13Z

On Wednesday 09 November 2005 12:59, Linus Torvalds wrote:
> > no. I said application _should_not_ depend on it, because it is a
> > undefined semantics.
>
> It's definitely neither unusual nor undefined. I do all my umounts by
> directory (in fact, doing it by anything else really _is_ badly defined,
> since a block device can be mounted in many places), and the only sane
> semantics would be to peel off the last mount on that directory.

I noticed this upgrading busybox mount a few months back. I was trying to
figure out if the correct semantics for umount /dev/block were to umount
_all_ instances of this block device, or umount just the most recent one. I
wound up just passing it through to the kernel and letting it decide, but I
wasn't sure why it did what it did.

The 2.6 multiple mount semantics are still new enough that the tools are just
now catching up. Last I checked, the standard mount was kind of unhappy with
--bind and --move mounts (they were corrupting /etc/mtab):

http://www.busybox.net/lists/busybox/2005-August/015285.html

The side effects of mount can be really non-obvious at times. For example,
while implementing busybox's switch_root I found out that this snippet of
klibc's run-init.c is slightly wrong:
if ( chdir(realroot) )
die("chdir to new root");
/* snip */
/* Overmount the root */
if ( mount(".", "/", NULL, MS_MOVE, NULL) )
die("overmounting root");

/* chroot, chdir */
if ( chroot(".") || chdir("/") )
die("chroot");

The || fallback in the third part won't work. chroot(".") will get you to the
new filesystem, but chdir("/") still gets you to the old one, even though
we've overmounted it. (I have no idea why. I assume it's because / is
special.)

Rob