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]

Date:	Thu, 05 Apr 2007 21:03:45 -0400
From:	Chris Snook <csnook@...hat.com>
To:	Chris Snook <csnook@...hat.com>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Robin Holt <holt@....com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Jack Steiner <steiner@...ricas.sgi.com>
Subject: Re: init's children list is long and slows reaping children.

Chris Snook wrote:
> Linus Torvalds wrote:
>>
>> On Thu, 5 Apr 2007, Robin Holt wrote:
>>> For testing, Jack Steiner create the following patch.  All it does
>>> is moves tasks which are transitioning to the zombie state from where
>>> they are in the children list to the head of the list.  In this way,
>>> they will be the first found and reaping does speed up.  We will still
>>> do a full scan of the list once the rearranged tasks are all removed.
>>> This does not seem to be a significant problem.
>>
>> I'd almost prefer to just put the zombie children on a separate list. 
>> I wonder how painful that would be..
>>
>> That would still make it expensive for people who use WUNTRACED to get 
>> stopped children (since they'd have to look at all lists), but maybe 
>> that's not a big deal.
> 
> Shouldn't be any worse than it already is.
> 
>> Another thing we could do is to just make sure that kernel threads 
>> simply don't end up as children of init. That whole thing is silly, 
>> they're really not children of the user-space init anyway. Comments?
>>
>>         Linus
> 
> Does anyone remember why we started doing this in the first place?  I'm 
> sure there are some tools that expect a process tree, rather than a 
> forest, and making it a forest could make them unhappy.
> 
> The support angel on my shoulder says we should just put all the kernel 
> threads under a kthread subtree to shorten init's child list and 
> minimize impact.  The hacker devil on my other shoulder says that with 
> usermode helpers, containers, etc. it's about time we treat it as a 
> tree, and any tools that have a problem with that need to be fixed.
> 
> -- Chris

Err, that should have been "about time we treat it as a forest".

-- Chris
-
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/