[PATCH] root-hopping for pre-2.3.41-3

Werner Almesberger almesber en lrc.di.epfl.ch
Mie Ene 26 02:51:23 CST 2000


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 en 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 en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



Más información sobre la lista de distribución Ayuda