As Eric pointed out, there is no problem with init starting with sid == pgid
== 0, and this was historical linux behavior changed in 2.6.18.
Remove kernel_init()->__set_special_pids().
This change and the previous change in daemonize() mean that /sbin/init does
not need the special "session != 1" hack in sys_setsid() any longer. We can't
remove this check yet, we should cleanup copy_process(CLONE_NEWPID) first, so
update the comment only.
Signed-off-by: Oleg Nesterov <[email protected]>
--- PT/init/main.c~4_glob_init 2007-11-26 16:56:24.000000000 +0300
+++ PT/init/main.c 2007-11-27 15:21:56.000000000 +0300
@@ -829,7 +829,6 @@ static int __init kernel_init(void * unu
*/
init_pid_ns.child_reaper = current;
- __set_special_pids(task_pid(current));
cad_pid = task_pid(current);
smp_prepare_cpus(max_cpus);
--- PT/kernel/sys.c~4_glob_init 2007-11-26 17:42:40.000000000 +0300
+++ PT/kernel/sys.c 2007-11-27 16:58:38.000000000 +0300
@@ -1054,12 +1054,11 @@ asmlinkage long sys_setsid(void)
if (group_leader->signal->leader)
goto out;
- /* Fail if a process group id already exists that equals the proposed
- * session id.
+ /* Fail if a process group id already exists that equals the
+ * proposed session id.
*
- * Don't check if session == 1 because kernel threads and CLONE_NEWPID
- * tasks use this session id and so the check will always fail and make
- * it so init cannot successfully call setsid.
+ * Don't check if session == 1, clone(CLONE_NEWPID) creates
+ * this group/session beforehand.
*/
if (session != 1 && pid_task(sid, PIDTYPE_PGID))
goto out;
Oleg Nesterov <[email protected]> writes:
> As Eric pointed out, there is no problem with init starting with sid == pgid
> == 0, and this was historical linux behavior changed in 2.6.18.
>
> Remove kernel_init()->__set_special_pids().
>
> This change and the previous change in daemonize() mean that /sbin/init does
> not need the special "session != 1" hack in sys_setsid() any longer. We can't
> remove this check yet, we should cleanup copy_process(CLONE_NEWPID) first, so
> update the comment only.
I guess that works. As long as we get there. We just need one more patch
in this series to fix the copy_process(CLONE_NEWPID).
Acked-by: "Eric W. Biederman" <[email protected]>
Eric W. Biederman wrote:
> Oleg Nesterov <[email protected]> writes:
>
>> As Eric pointed out, there is no problem with init starting with sid == pgid
>> == 0, and this was historical linux behavior changed in 2.6.18.
>>
>> Remove kernel_init()->__set_special_pids().
>>
>> This change and the previous change in daemonize() mean that /sbin/init does
>> not need the special "session != 1" hack in sys_setsid() any longer. We can't
>> remove this check yet, we should cleanup copy_process(CLONE_NEWPID) first, so
>> update the comment only.
>
> I guess that works. As long as we get there. We just need one more patch
> in this series to fix the copy_process(CLONE_NEWPID).
I hope this will NOT be the fix that creates the namespace's
init with the pid == 0 ;)
> Acked-by: "Eric W. Biederman" <[email protected]>
Pavel Emelyanov <[email protected]> writes:
> Eric W. Biederman wrote:
>> Oleg Nesterov <[email protected]> writes:
>>
>>> As Eric pointed out, there is no problem with init starting with sid == pgid
>>> == 0, and this was historical linux behavior changed in 2.6.18.
>>>
>>> Remove kernel_init()->__set_special_pids().
>>>
>>> This change and the previous change in daemonize() mean that /sbin/init does
>>> not need the special "session != 1" hack in sys_setsid() any longer. We can't
>>> remove this check yet, we should cleanup copy_process(CLONE_NEWPID) first, so
>>> update the comment only.
>>
>> I guess that works. As long as we get there. We just need one more patch
>> in this series to fix the copy_process(CLONE_NEWPID).
>
> I hope this will NOT be the fix that creates the namespace's
> init with the pid == 0 ;)
No just with session == pgrp == (unchanged and thus with vpid 0).
Eric