mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kyle Moffett <mrmacman_g4@mac.com>
To: Rob Landley <rob@landley.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Which process context does /sbin/hotplug run in?
Date: Mon, 15 May 2006 00:17:44 -0400	[thread overview]
Message-ID: <6BCF90AC-FF8B-48BC-8659-DBE0DD00E270@mac.com> (raw)
In-Reply-To: <200605142008.39420.rob@landley.net>

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




  reply	other threads:[~2006-05-15  4:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-12 18:20 Rob Landley
2006-05-13  7:24 ` Kyle Moffett
2006-05-15  0:08   ` Rob Landley
2006-05-15  4:17     ` Kyle Moffett [this message]
2006-05-15  4:28       ` Joshua Hudson
2006-05-15 19:59       ` Rob Landley
2006-05-15 22:22         ` Kyle Moffett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6BCF90AC-FF8B-48BC-8659-DBE0DD00E270@mac.com \
    --to=mrmacman_g4@mac.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rob@landley.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®