linux-kernel - Re: [patch 0/2] cpusets, cpu_cgroup: disallow attaching kthreadd

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, 5 Apr 2012 14:26:34 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Tejun Heo <tj@...nel.org>
cc:	Mike Galbraith <mgalbraith@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Menage <paul@...lmenage.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Li Zefan <lizefan@...wei.com>
Subject: Re: [patch 0/2] cpusets, cpu_cgroup: disallow attaching kthreadd

On Thu, 5 Apr 2012, Tejun Heo wrote:

> > Rebased and separated patches proposed by Mike Galbraith 
> > <mgalbraith@...e.de> in https://lkml.org/lkml/2012/1/7/17.
> 
> Umm... David, I'm with Peter on this one and don't want kthreadd to go
> anywhere other than the root cgroup.  If you know of a valid use case,
> please bring one up; otherwise, I'm applying Mike's patch.
> 

Yeah, I know a valid use case, and I'm surprised you don't.

Google is moving in a direction where nothing will be assigned to the root 
memcg.  We already have a seperate memcg for accounting of memory 
allocated by the kernel, i.e. memory not accounted toward any user job.  
We will be doing this more aggressively in the future once we have setup 
memcg hierarchies to differentiate the memory usage of the kernel 
including workqueues created by kthreadd and have complete coverage of 
memory accounting such as slab and memory allocated directly from 
__get_free_pages().  We don't want anything in the root memcg itself.

It's also possible to attach kthreadd to the cpuacct cgroup for similar 
accounting.  The idea is that not all cgroups impose limits, either for 
memcg (where memory.limit_in_bytes == ULONG_MAX) or cpuacct, but rather 
purely for accounting.

For cpusets and the cpu cgroup, I completely agree with disallowing 
kthreadd and that's why I've passed along these patches.  However, it's 
not necessary (or even preferred for our usecase) to restrict kthreadd 
from being attached to all cgroups.  Yes, it's a global resource.  We want 
to account for the memory of that global resource.

Thanks.
--
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/