linux-kernel - Re: [patch 00/18] SMP: Boot and CPU hotplug refactoring

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: <20120420154202.GB32324@google.com>
Date:	Fri, 20 Apr 2012 08:42:02 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>, linux-arch@...r.kernel.org,
	Rusty Russell <rusty@...tcorp.com.au>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Ingo Molnar <mingo@...nel.org>,
	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
	David Rientjes <rientjes@...gle.com>
Subject: Re: [patch 00/18] SMP: Boot and CPU hotplug refactoring - Part 1

Hello,

On Fri, Apr 20, 2012 at 03:21:38PM +0200, Peter Zijlstra wrote:
> On Fri, 2012-04-20 at 13:05 +0000, Thomas Gleixner wrote:
> > This first part moves the idle thread management for non-boot cpus
> > into the core. fork_idle() is called in a workqueue as it is
> > implemented in a few architectures already. This is necessary when not
> > all cpus are brought up by the early boot code as otherwise we would
> > take a ref on the user task VM of the thread which brings the cpu up
> > via the sysfs interface. 
> 
> So I was thinking about this and I think we should make that kthreadd
> instead of a random workqueue thread due to all that cgroup crap. People
> are wanting to place all sorts of kernel threads in cgroups and I'm
> still arguing that kthreadd should not be allowed in cgroups.
>
> Tejun, what's the status of that patch? Afaict David Rientjes's use-case
> is insane and mostly a side effect of memcg broken-ness.

I'm still leaning towards restricting kthreadd and any PF_THREAD_BOUND
threads in the root cgroup.  I'm not sure about !BOUND kthreads tho.
It doesn't make sense for the most part but there are cases
(e.g. crypto kthreads) which might make some sense.

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/