Stupid question bout the interaction of initramfs, hotplug, and per-process
filesystem namespaces:
I do this from initramfs:
echo /sbin/mdev > /proc/sys/kernel/hotplug
At the moment I do that, the first "/" in /sbin/mdev points to rootfs.
Shortly thereafter I do a switch_root, which does a chroot. Does hotplug
still point into rootfs? Or does it point to whatever "/" for PID 1 points
to now?
Since every process could be in a different chroot environment, how do I know
which process context the kernel_thread that call_usermodehelper() runs in
was parented from? It seems random: the x86 implementation of
call_usermodehelper() is calling do_fork(), and seems to be using the
namespace of whatever process it's running in. Which could be a chroot
process that doesn't have the hotplug I pointed it at visible in its
namespace at all...
Anybody know this one? Now that filesystem namespaces are per-process, and
move/bind mounts let us have cycles in our trees, as far as I can tell we
could actually have two completely detached namespaces with different sets of
processes in each. A path to hotplug isn't
Rob
P.S: mount a filesystem under itself. Fun for the whole family:
mount -t tmpfs /tmp /tmp
cd /tmp
mkdir sub
mount --bind sub /var
cd /var
mkdir sub2
mount --move /tmp sub2
--
Never bet against the cheap plastic solution.
On May 12, 2006, at 14:20, Rob Landley wrote:
> Anybody know this one? Now that filesystem namespaces are per-
> process, and move/bind mounts let us have cycles in our trees,
Actually; it doesn't. Your example below looks like this:
> mount -t tmpfs /tmp /tmp
> cd /tmp
> mkdir sub
> mount --bind sub /var
> cd /var
> mkdir sub2
> mount --move /tmp sub2
/
/var
/var/sub
/var/sub2
/var/sub2/sub
/var/sub2/sub2
The recursion ends there. Basically with the first bind mount you
attach the same instance of tmpfs to /tmp and /var, then you move the
tmpfs from /tmp to the "/sub2" directory in the "/var" tmpfs
_mountpoint_. It's kind of confusing behavior; but the directory
tree and the mount tree are basically kind of separate entities in a
sense.
Cheers,
Kyle Moffett
--
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.
-- Brian Kernighan
On Saturday 13 May 2006 3:24 am, Kyle Moffett wrote:
> /
> /var
> /var/sub
> /var/sub2
> /var/sub2/sub
> /var/sub2/sub2
>
> The recursion ends there. Basically with the first bind mount you
> attach the same instance of tmpfs to /tmp and /var, then you move the
> tmpfs from /tmp to the "/sub2" directory in the "/var" tmpfs
> _mountpoint_. It's kind of confusing behavior; but the directory
> tree and the mount tree are basically kind of separate entities in a
> sense.
I can CD into them endlessly, and both "ls -lR" and "find ." report cycles in
the tree, which surprised me that they had a specific error message for that,
actually. Good enough for me. :)
And I'm not _complaining_ about it. Just fiddling around with fun stuff. If
I get really bored I'll figure a way to split the tree so there are two
completely unconnected mount trees in different processes. (Get a private
namespace that's chrooted into something that somebody else does a umount -l
on from their space. Or without using umount -l, just have two processes
chroot into other mount points which should theoretically garbage collect the
old root if no processes still references it, which presumably means one of
the processes is init...)
Don't mind me, I do this for fun.
Rob
--
Never bet against the cheap plastic solution.
On May 14, 2006, at 20:08, Rob Landley wrote:
> On Saturday 13 May 2006 3:24 am, Kyle Moffett wrote:
>> /
>> /var
>> /var/sub
>> /var/sub2
>> /var/sub2/sub
>> /var/sub2/sub2
>>
>> The recursion ends there. Basically with the first bind mount you
>> attach the same instance of tmpfs to /tmp and /var, then you move
>> the tmpfs from /tmp to the "/sub2" directory in the "/var" tmpfs
>> _mountpoint_. It's kind of confusing behavior; but the directory
>> tree and the mount tree are basically kind of separate entities in
>> a sense.
>
> I can CD into them endlessly, and both "ls -lR" and "find ." report
> cycles in the tree, which surprised me that they had a specific
> error message for that, actually. Good enough for me. :)
Odd, I'm unable to replicate that behavior here. If I run "ls /var/
sub2/sub2" I don't get any entries. Find and ls -lR have error
messages of that because it can occasionally be triggered with
symlinks and such.
> And I'm not _complaining_ about it. Just fiddling around with fun
> stuff. If I get really bored I'll figure a way to split the tree
> so there are two completely unconnected mount trees in different
> processes. (Get a private namespace that's chrooted into
> something that somebody else does a umount -l on from their space.
> Or without using umount -l, just have two processes chroot into
> other mount points which should theoretically garbage collect the
> old root if no processes still references it, which presumably
> means one of the processes is init...)
Well, actually, it isn't that hard. Just run something like this:
#! /bin/sh
mkdir /a
mkdir /b
mount -t tmpfs tmpfs /a
mount -t tmpfs tmpfs /b
mkdir /a/old
mkdir /b/old
tool_to_fork_in_new_namespace sh -c "pivot_root /a /a/old && umount -
l /a/old && read"
pivot_root /b /b/old && umount -l /b/old && read
All you need to write is tool_to_fork_in_new_namespace which does
clone(CLONE_NEWNS) followed by exec().
Cheers,
Kyle Moffett
--
Simple things should be simple and complex things should be possible
-- Alan Kay
>
> > And I'm not _complaining_ about it. Just fiddling around with fun
> > stuff. If I get really bored I'll figure a way to split the tree
> > so there are two completely unconnected mount trees in different
> > processes. (Get a private namespace that's chrooted into
> > something that somebody else does a umount -l on from their space.
> > Or without using umount -l, just have two processes chroot into
> > other mount points which should theoretically garbage collect the
> > old root if no processes still references it, which presumably
> > means one of the processes is init...)
>
> Well, actually, it isn't that hard. Just run something like this:
>
> #! /bin/sh
> mkdir /a
> mkdir /b
> mount -t tmpfs tmpfs /a
> mount -t tmpfs tmpfs /b
> mkdir /a/old
> mkdir /b/old
> tool_to_fork_in_new_namespace sh -c "pivot_root /a /a/old && umount -
> l /a/old && read"
> pivot_root /b /b/old && umount -l /b/old && read
>
> All you need to write is tool_to_fork_in_new_namespace which does
> clone(CLONE_NEWNS) followed by exec().
>
> Cheers,
> Kyle Moffett
>
I've done that "two disconnected trees" in 2.0 kernel. Boot with an initrd.
/linuxrc runs something in the background (telnet server, just for kicks)
/initrd doesn't exist ont the new root.
So, try mount new root succeeds, but try unmount old root fails.
Presto. Two disconnected trees.
I wonder if it still works.
On Monday 15 May 2006 12:17 am, Kyle Moffett wrote:
> > I can CD into them endlessly, and both "ls -lR" and "find ." report
> > cycles in the tree, which surprised me that they had a specific
> > error message for that, actually. Good enough for me. :)
>
> Odd, I'm unable to replicate that behavior here. If I run "ls /var/
> sub2/sub2" I don't get any entries. Find and ls -lR have error
> messages of that because it can occasionally be triggered with
> symlinks and such.
Perhaps I copied it down wrong. I did this in a 2.6.16 UML instance...
sh-3.00# mount -t tmpfs /tmp /tmp
sh-3.00# cd /tmp
sh-3.00# mkdir woot
sh-3.00# mount --bind woot /var
sh-3.00# cd /var
sh-3.00# mkdir sub
sh-3.00# mount --move /tmp sub
sh-3.00# ls -lR
.:
total 0
drwxrwxrwt 3 root root 60 May 15 15:57 sub
./sub:
total 0
drwxr-xr-x 3 root root 60 May 15 15:57 woot
ls: not listing already-listed directory: ./sub/woot
sh-3.00# find .
.
./sub
find: Filesystem loop detected; `./sub/woot' has the same device number and
inode as a directory which is 2 levels higher in the filesystem hierarchy.
./sub/woot
sh-3.00#
Works for me. :)
> --
> Simple things should be simple and complex things should be possible
> -- Alan Kay
And crazy things fun. :)
Rob
--
Never bet against the cheap plastic solution.
On May 15, 2006, at 15:59, Rob Landley wrote:
> On Monday 15 May 2006 12:17 am, Kyle Moffett wrote:
>>> I can CD into them endlessly, and both "ls -lR" and "find ."
>>> report cycles in the tree, which surprised me that they had a
>>> specific error message for that, actually. Good enough for me. :)
>>
>> Odd, I'm unable to replicate that behavior here. If I run "ls /
>> var/sub2/sub2" I don't get any entries. Find and ls -lR have
>> error messages of that because it can occasionally be triggered
>> with symlinks and such.
>
> Perhaps I copied it down wrong. I did this in a 2.6.16 UML
> instance...
>
> sh-3.00# mount -t tmpfs /tmp /tmp
> sh-3.00# cd /tmp
> sh-3.00# mkdir woot
> sh-3.00# mount --bind woot /var
> sh-3.00# cd /var
> sh-3.00# mkdir sub
> sh-3.00# mount --move /tmp sub
> sh-3.00# ls -lR
> .:
> total 0
> drwxrwxrwt 3 root root 60 May 15 15:57 sub
>
> ./sub:
> total 0
> drwxr-xr-x 3 root root 60 May 15 15:57 woot
> ls: not listing already-listed directory: ./sub/woot
> sh-3.00# find .
> .
> ./sub
> find: Filesystem loop detected; `./sub/woot' has the same device
> number and
> inode as a directory which is 2 levels higher in the filesystem
> hierarchy.
> ./sub/woot
> sh-3.00#
>
> Works for me. :)
I get the exact same behavior, but:
sh-3.00# ls -alh /var/sub/woot/sub
total 0
drwxr-xr-x 2 root root 40 May 15 18:09 .
drwxr-xr-x 3 root root 60 May 15 18:09 ..
sh-3.00#
It does *not* recurse indefinitely here, because the mount tree is
not recursive. A bind mount (Or a --move, which is bind and umount -
l), does not share submounts, so it's impossible to circularly link
them. This is why it's possible to do this:
mount --bind /var /apache1/bin
mount --bind /var /apache2/var
mount --bind /www1 /apache1/var/www
mount --bind /www2 /apache2/var/www
Cheers,
Kyle Moffett
--
There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult.
-- C.A.R. Hoare