Hubertus Franke <[email protected]> writes:
>> From the kernel community at large I am asking:
>> Does the code look generally sane?
>
> Yes, but I have one question for you...
> Large parts of the patch are adding the pspace argument
> to find_task_by_pid() and in many cases that argument is
> current->pspace.
> It might bring down the size of the patch if you
> have
>
> find_task_by_pid( pid ) { return find_task_pidspace_by_pid ( current->pspace,
> pid ); }
>
> and then only deal with the exceptional cases using find_task_pidspace_by_pid
> when the pidspace is different..
That is a possibility. However I want to break some eggs so that the
users are updated appropriately. It is only by a strenuous act of
will that I don't change the type of pid,tgid,pgrp,session.
The size of the changes is much less important than being clear.
So for I want find_task_by_pid to be an absolute interface.
>> Does the use of clone to create a new namespace instance look
>> like the sane approach?
>>
>
> At he surface it looks OK .. how does this work in a multi-threaded
> process which does cloen ( CLONE_NPSPACE ) ?
> We discussed at some point that exec is the right place to do it,
> but what I get is that because this is the container_init task
> we are OK !
> A bit clarification would help here ...
Well the parent doesn't much matter. But the child must have a fresh
start on all the groups of processes. As all other groupings known by
a pid are per pspace, so they can't cross that line.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
