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]

Message-ID: <20120406155203.GA4798@dhcp-172-17-108-109.mtv.corp.google.com>
Date:	Fri, 6 Apr 2012 08:52:03 -0700
From:	Tejun Heo <tj@...nel.org>
To:	David Rientjes <rientjes@...gle.com>
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

Hello, David.

On Thu, Apr 05, 2012 at 04:40:06PM -0700, David Rientjes wrote:
> Well, I'm fussing over it because the patch being considered unnecessary 
> requires that kthreadd can't be moved anywhere and I know one company is 
> trying to move in a direction where nothing is in the root memcg.

"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.  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.

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.  If bound kthreads in !root cgroups cause issues for some and
there aren't quite strong reasons to do otherwise, I would just
restrict them in the root.  It's not like those kthreads are
cgroup-aware in any form anyway.

I don't know.  Just proceed without kthreadd in the root.  If the
fallouts are big enough and can't be easily worked around, let's talk
then.

Thanks.

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