lkml.org 
[lkml]   [2000]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] root-hopping for pre-2.3.41-3
    Date
    Linus Torvalds wrote:
    > - your MNT_DETACH thing is a "umount" flag, and I think that is
    > fundamentally flawed. It's a separate operation entirely. If we want to
    > root-hop, what we should do is rather simple:

    The reason why I added it to umount is that I wanted to have transaction
    semantics, such that things don't get weird if we hit a problem in the
    middle. But this is not strictly necessary, I agree.

    > - detach the trees and haev two trees. This is not the same as
    > "umount" at all, this is really just
    >
    > struct dentry *mnt = dentry_lookup("new_root_path");

    I see what you mean. This takes away the possibility of detaching
    multiple directories at the same time, e.g. if I have /, /new-root,
    and /proc, and then I make a chroot to /new-root, I can still reach
    the former /new-root (now /), but /proc is lost forever.

    This can be avoided by allowing access via block devices, a la
    umount, which should probably be implemented using umount and a new
    flag ;-) What do you think ? I kind of like to allow people to
    recover from their mistakes. Also, this avoids the introduction of
    a new system call, ioctl, or such.

    > I don't think your "complicate the normal umount with new flags" approach
    > is needed at all.

    Does this objection also apply to MNT_CHROOT ? This could of course
    become something like chroot2("new-root",pid), but it seems a bit messy
    to me if the user has to track down all the kernel threads first (and
    that repeatedly, because some of them may have spawned new threads
    during the scan).

    > Also, /proc/mounts should just use the dentry and the path lookup function
    > (d_path()) to create the /proc/mounts output on-the-fly, and that will get
    > the name right whatever happens (_including_ a rename of the whole
    > mount-point path, which neither the current approach nor your approach
    > gets right at all.

    Hmm, how would you handle this:
    - we start with / (mounted from hda1), /newroot, /proc
    - exec chroot /newroot /bin/sh </newroot/dev/console etc.
    mount -t proc /proc /proc
    cat /proc/mounts

    1) The old behaviour would have yielded /, /proc, /newroot, /proc
    2) Only d_path would yield: /, /proc, /, /proc
    3) My approach yields: 03:01/, 03:01/proc, /, /proc

    1 and 2 have ambiguous entries. 3 changes the syntax for those entries
    for which no valid path name exists under the current root. In addition
    to that, only 3) gives you the information you need to unmount the old
    / and the old /proc (if you allow this case).

    Would you prefer simply the device numbers, without path, e.g.
    03:01, 00:01, /, /proc ?

    Cheers, Werner

    --
    _________________________________________________________________________
    / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch /
    /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:56    [W:4.854 / U:0.380 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site