linux-kernel - Re: init's children list is long and slows reaping children.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m1lkh58q16.fsf@ebiederm.dsl.xmission.com>
Date:	Fri, 06 Apr 2007 09:45:57 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Oleg Nesterov <oleg@...sign.ru>
Cc:	Robin Holt <holt@....com>, Chris Snook <csnook@...hat.com>,
	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: init's children list is long and slows reaping children.

Oleg Nesterov <oleg@...sign.ru> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/