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:	Fri, 6 Apr 2012 13:46:56 -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 Fri, 6 Apr 2012, Tejun Heo wrote:

> "Nothing in the root memcg" can't be a goal in and of itself.  You
> want that to achieve some functional goal and I'm trying to say this
> specific kthreadd change doesn't necessarily affect the goal - better
> accounting - all that much.  If root group is gonna be completely
> empty otherwise, just combine information from it.

That doesn't work, the kmem extension to memcg does not allow slab to be 
properly accounted to threads in the root memcg.  From 
Documentation/cgroups/memory.txt section 2.7:

"Kernel memory limits are not imposed for the root cgroup. Usage for the 
root cgroup may or may not be accounted."

Kernel memory, I'm sure we'll all agree, is particularly pertinent for 
kthreadd and would really be the most interesting reason to ever move it 
to a different memcg.  This is the use-case that I cited when I said we're 
moving in a direction to have nothing in the root memcg, for finer-grained 
accounting of kernel memory.

> Even if that
> doesn't work, assigning specific kthreads to appropriate cgroups after
> the creation wouldn't be too far off.  I just don't see how relevant
> it actually would be.
> 

What about for workqueues?

> If we want all controlles to play by the same rules, which is
> necessary for having a unified hierarchy, I wanna keep those rules
> simple.

That's a different goal, in my opinion.  We already talked about how we 
relax the restriction on PF_THREAD_BOUND for both cpusets and cpuacct by 
doing -EINVAL for changes to a cgroup that include such threads that are 
invalid (for cpusets, changing cpuset.mems to be different than the bound 
cpu; for cpu, force rt_runtime for attachment).  If we do that then we 
don't need any special handling of kthreadd either, which is the direction 
in which I thought this discussion was going.

In the interim, however, we need a restriction in place for kthreadd for 
both cgroups until such time as that is made a reality.  It's not like 
we're going to dictate everyone use a signal hierarchy in 3.4.
--
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/