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

From: Rob Landley (rob_at_landley.net)
Date: 11/16/05

  • Next message: Christoph Hellwig: "Re: [PATCH 1/4] add compat_ioctl methods to dasd" 
    To: Linus Torvalds <torvalds@osdl.org>
Date:	Wed, 16 Nov 2005 02:41:19 -0600

    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

    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/

  • Next message: Christoph Hellwig: "Re: [PATCH 1/4] add compat_ioctl methods to dasd"

    Relevant Pages

    • cannot boot-up linux, unable to read superblock
      ... mount: error 22 mounting ext3 ... enable lvm and tried fsck for the volumes (one is empty volume? ... Attempt to read block from filesystem resulted in short read while trying to open /dev/VolGroup00/LogVol00 ...
      (RedHat)
    • Re: Add a norecovery option to ext3/4?
      ... When the filesystem is told to mount the disk read only, ... IO in the course of making that read-only mount available. ... In that case you are mounting the same filesystem uner 2 different ...
      (Linux-Kernel)
    • Re: Add a norecovery option to ext3/4?
      ... I argue that historically the primary use of the read only mount flag was to prevent the underlying filesystem from being modified and possibly damaged further before it can be fsck'ed. ... It became common practice to mount the root filesystem read only and run a fsck on it, then either reboot or remount read-write depending on if fsck had to make changes. ... You might not read the correct data from it, but you would not damage the underlying data simply by mounting it read-only. ...
      (Linux-Kernel)
    • Force mount with HPUX 11.00 when Block Read Error
      ... This error can't be fixed by fsck. ... find suggest to force the mounting of the involved filesystem. ... find a -f switch in HPUX 11.00, so I can't mount the filesystem. ...
      (comp.sys.hp.hpux)
    • vfat iPod suddenly fails to write [was: Re: [solved] Re: mounting iPod with USB]
      ... >>which is just wack, afaict, seeing as it was mounting happily with ... > the sda3 is the one to mount. ... Sep 28 12:14:44 homeruns kernel: FAT: Directory bread ...
      (Debian-User)