Messages in this thread | | | From | Rob Landley <> | Subject | Re: [PATCH 12/18] shared mount handling: bind and rbind | Date | Tue, 15 Nov 2005 21:29:03 -0600 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |