[Devel] Re: [PATCH] [RFC] c/r: Add UTS support

[Mike Waychison]

Eric W. Biederman wrote:
> Mike Waychison <mikew at google.com> writes:
> 
>> Eric W. Biederman wrote:
>>> Mike Waychison <mikew at google.com> writes:
>>>
>>>> Cedric Le Goater wrote:
>>>>> Dan Smith wrote:
>>>>>> SH> (Note that in Dan's next version, he did move unshare into
>>>>>> SH> userspace)
>>>>>>
>>>>>> The idealist in me still wants it to be in the kernel.  However, after
>>>>>> seeing it done I agree that it's the right thing to do, at least in
>>>>>> this case.
>>>>> I would say in all cases.
>>>>>
>>>>> as you can't unshare(CLONE_NEWPID), 
>>>> Eric,
>>>>
>>>> Is there a particular reason the above doesn't work?  I made an attempt to
>>>> implement it a while back, but haven't convinced myself that signals and
>>>> re-attaching a new struct pid to a running task is correct.
>>> Last time I was thinking about this I figured unsharing a pid namespace would
>>> simply place it's children in a different pid namespace, not the originating
>>> process.
>>>
>>> Would that semantic be useful?  It would certainly be a lot less effort than
>>> changing the pid on a running process correctly.
>> Hmm, that would be a little odd.  I think getting the unsharing task to become
>> pid 1 is a bit easier to understand and it makes it clear which task is the
>> reaper for the new namespace.  Otherwise the first child becomes pid 1 but it
>> isn't the reaper.
> 
> For very lightweight pid namespaces that may be desirable, and that is where
> all of this conversation originally started.   I am happy to set the starting
> pid to 2 to avoid confusion on that point.

I wasn't really taking into consideration the notion of a 'lightweight' 
pid namespace that didn't have a 'container-init' process.

> 
> One of the other problems with changing the pid is that user space in general
> glibc in particular can not cope with the pid of a process changing.
> 
> My memories are foggy at the moment but I do know that on the several occasions
> we have looked at unshare of the pid namespace it has failed due to kernel issues.
> I also remember I was close to having resolved the issues of unsharing the pid
> namespace if we did not change the pid of processing calling unshare.

Do you have pointers to discussions about these issues?

> You did not answer my question.  I don't quite see how you were envisioning
> using unsharing the pid namespace as part of restart so I can't tell if my
> proposed semantics would work for that case.

Well, one way to look at doing restart with nested namespaces would be 
to have userland go off and begin by rebuilding the process tree.  While 
rebuilding, any given process being recreated would need to have the 
same pid in the parenting pid namespace (the outer most namespace in the 
container).  It would need to know if it 'got' the right pid, and if so, 
would then create the new child pid namespace.  Requiring CLONE_NEWPID 
set on each and every clone(2) [*] would certainly be possible, as long 
as we had some way for the task being created to know what it's parent 
namespace pid is.  I guess this could be done by a shared memory segment 
shared between the parent and child of the clone as well, though it 
doesn't seem as clear-cut to me.



[*] Yes, I'm dancing around the clone_with_pid issue..
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers