Which process context does /sbin/hotplug run in?

Which process context does /sbin/hotplug run in?

[Rob Landley]

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.

Re: Which process context does /sbin/hotplug run in?

[Kyle Moffett]

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

Re: Which process context does /sbin/hotplug run in?

[Rob Landley]

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.

Re: Which process context does /sbin/hotplug run in?

[Kyle Moffett]

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

Re: Which process context does /sbin/hotplug run in?

[Joshua Hudson]

>
> > 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.

Re: Which process context does /sbin/hotplug run in?

[Rob Landley]

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.

Re: Which process context does /sbin/hotplug run in?

[Kyle Moffett]

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