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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 5 Apr 2012 16:05:43 -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:

> > > I can see your point but the problem is that it conflicts with the
> > > long term direction cgroup is taking and that cgroup seems generally
> > > over-engineered to allow too many things which aren't too necessary to
> > > the point where it's a giant pain in the ass for the subsystems and
> > > people involved, so I'm far more likely to go for chopping down and
> > > restricting stuff if it's not strictly necessary.
> > 
> > How does kthreadd's placement conflict with the long-term direction of 
> > cgroups?
> 
> Because there's only single hierarchy, random subsystem saying no on
> ->can_attach() doesn't work.
> 

The cgroups of interest here, cpusets and cpu, which have restrictions for 
PF_THREAD_BOUND threads is disjoint from memcg and cpuacct, which I'm 
saying it's useful for.  There's no requirement to mount them all.  But if 
you do try to do memory accounting in the presence of cpusets, though, it 
should be restricted.

We could still move to a single hierarchy, though, if we introduced a 
change to allow PF_THREAD_BOUND to attach to both cpusets and cpu iff 
its bound cpu is allowed and then do -EINVAL if its changed while still 
attached.
--
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/