linux-kernel - Re: [patch] cgroups: 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:	Wed, 4 Apr 2012 16:09:22 -0700
From:	Tejun Heo <tj@...nel.org>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Mike Galbraith <mgalbraith@...e.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Li Zefan <lizf@...fujitsu.com>,
	Paul Menage <paul@...lmenage.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [patch] cgroups: disallow attaching kthreadd

On Wed, Apr 04, 2012 at 02:17:36PM -0700, David Rientjes wrote:
> On Wed, 4 Apr 2012, Mike Galbraith wrote:
> 
> > > I've never seen a nack from Peter on this, I only remember discussing 
> > > whether this needs to be isolated to only cpusets or whether it needs to 
> > > be a generic cgroup thing and I've always argued in favor of localizing it 
> > > to cpusets because that cgroup happens to care about cpu affinity where 
> > > others don't and this is why cgroups have ->can_attach() functions.  If a 
> > > cgroup were created to have nothing to do with cpu affinity (only for 
> > > collecting statistics for threads within it, for example), there's 
> > > absolutely no reason why we need to exclude kthreadd.
> > 
> > Well, he didn't actually say "NAK", but was against it, which means
> > pretty much the same thing as NAK to me.. we can call it a nak.
> > 
> 
> People are able to change their minds and after our discussion about 
> cgroups vs cpusets, I was under the impression we were at a common 
> understanding of the problem.
> 
> Cpusets are a cgroup.  It wouldn't make much sense to NACK a patch that 
> does this to cpusets if you're arguing in favor of doing it for all 
> cgroups.
> 
> Your changelog mentions only cpusets issues, not cgroup issues.
> 
> So please propose your cpusets version so that the issue can be fixed.  If 
> Peter wants to extend that to cgroups later, that's a discussion we can 
> have at that time.  However, the bug being addressed here is for cpusets 
> and is deserving of a patch now rather than later.  I'm concerned we're 
> just going to drop this again and it will live on.

I don't see much problem with the proposed solution and am gonna take
it unless there are pretty good reasons not to.

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/