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:0.065 / U:0.492 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site