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: <alpine.DEB.2.00.1204051454070.17852@chino.kir.corp.google.com>
Date:	Thu, 5 Apr 2012 15:03:06 -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:

> Ambitious and I'm not even sure that's even possible without fallback
> default group.  There just are things which are system-wide.  What's
> wrong with using root cgroup for that?
> 

Yes, they act system-wide but that doesn't mean their memory usage or cpu 
need to be accounted together.  The key is that all cgroups, current or 
future, aren't necessarily for limiting those system-wide resources but 
rather can provide useful insight into their cost by monitoring either 
their memory or cpu through these two cgroups.

kthreadd certainly is not the only system-wide resource on the kernel; so 
why are you not arguing that all PF_KTHREAD threads not be allowed into 
non-root cgroups?  We actually have many kthreads in a memcg that _is_ 
limited to a specific amount of memory together with other system daemons 
that are killable if it becomes oom.

The reason we're discussing kthreadd here is because it has the funny 
ability to fork other kthreads that become PF_THREAD_BOUND.  Usually the 
only PF_THREAD_BOUND threads are ones created at boot.  However, if a 
kthread is started for a specific cpu, it gets this bit set to stay on 
that cpu via kthread_bind().  That's what causes an inconsistency for only 
two types of cgroups: cpusets and cpu and we don't allow them to move 
amongst them because of that.

That's what this patch series addresses.  Please don't unnecessarily limit 
our ability with kthreadd or kthreads in general for accounting of system 
activity.
--
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/