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

[Rob Landley <rob@landley.net>]

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