Oleg Nesterov <[email protected]> writes:
>> At first glance your patch looks reasonable.
>>
>> Unfortunately it only applies to the rare thread that calls daemonize,
>> and not also to kernel/kthread/kthread() which means it will miss many of
>> our current kernel threads.
>
> Note that a thread created by kthread_create() has ->parent == "[kthread]",
> not /sbin/init (unless it was created before core_initcall). So I don't really
> understand how stop_machine() creates the threads parented to init.
Duh. I was looking for that detail but the code was sufficiently
abstracted that I missed it skimming through. Now I see it thanks.
That at least explains how a handful of threads created with
kthread_create have init as their parent.
My gut feel says it makes sense to change reparent_to_init to
reparent_to_kthread. Which will get the all of the kernel daemons
under a single parent. Further I think it makes sense to see if
we can start kthread earlier. Having kthread have pid == 2 would be
nice. That way we can kill the conditional that is only used during
early initialization (make the code simpler and more predictable).
Since we seem to need kthread for the work of forking kernel threads,
I don't see much point in not having a proper process tree, and a
single extra child for pid == 1 isn't going to hurt anyone.
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]
