Any reason why daemonized kthread still uses 1,1 special pids? This patch
sets 0,0 pids, this matches kthread_create'ed threads.
Signed-off-by: Oleg Nesterov <[email protected]>
--- PT/kernel/exit.c~3_daemonize_swapper 2007-11-26 16:47:35.000000000 +0300
+++ PT/kernel/exit.c 2007-11-26 17:10:41.000000000 +0300
@@ -390,7 +390,7 @@ void daemonize(const char *name, ...)
get_nsproxy(&init_nsproxy);
switch_task_namespaces(current, &init_nsproxy);
}
- set_special_pids(find_pid(1));
+ set_special_pids(&init_struct_pid);
proc_clear_tty(current);
/* Block and flush all signals */
On 11/26, Oleg Nesterov wrote:
>
> Any reason why daemonized kthread still uses 1,1 special pids?
Actually, I guess the reason is that this was not possible before.
Now that set_special_pids uses "struct pid" we can do this.
Perhaps it is better to move the callsite to reparent_to_kthreadd()
and kill set_sepcial_pids().
Oleg.
Oleg Nesterov <[email protected]> writes:
> Any reason why daemonized kthread still uses 1,1 special pids? This patch
> sets 0,0 pids, this matches kthread_create'ed threads.
You got it in your reply...
> Signed-off-by: Oleg Nesterov <[email protected]>
Acked-by: "Eric W. Biederman" <[email protected]>
Hmm. I wonder if we could ensure kernel_thread always
returns a global pid_t, and then reallocate the struct
pid for the task we have just daemonized so that it only
has a single pid in the init_pid_ns.
That would remove our capturing of child pid namespaces.
Eric
[email protected] (Eric W. Biederman) writes:
> Hmm. I wonder if we could ensure kernel_thread always
> returns a global pid_t, and then reallocate the struct
> pid for the task we have just daemonized so that it only
> has a single pid in the init_pid_ns.
Well we can't reallocate the struct pid, if anyone was using
it we would have problems, but we can certainly remove all
pid_t values except for those in the init_pid_ns.
We definitely have some serious issues with kernel_thread
and signal sending though.
Eric