linux-kernel - Re: [RFC] Restrict kernel spawning of threads to a specified set of cpus.

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: <00000141179a5b1f-b94a8394-9e98-400c-ae7f-59cdcfce60a6-000000@email.amazonses.com>
Date:	Fri, 13 Sep 2013 13:54:53 +0000
From:	Christoph Lameter <cl@...ux.com>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Gilad Ben-Yossef <gilad@...yossef.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Mike Frysinger <vapier@...too.org>,
	linux-kernel@...r.kernel.org,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [RFC] Restrict kernel spawning of threads to a specified set of
 cpus.


> > If we really want to solve that race, then may be we can think of a kernel_parameter
>
> No bloody kernel params. I'd much rather create a pointless kthread to
> act as usermodehelper parent that people can set context on (move it
> into cgroups, set affinity, whatever) so it automagically propagates to
> all userspace helper thingies.
>
> Is there anything other than usermodehelper we need to be concerned
> with? One that comes to mind would be unbound workqueue threads. Do we
> want to share the parent with usermodehelpers or have these two classes
> have different parents?

So you want to keep those silly racy move-all-threads-to-some-cpus scripts
around? A kernel parameter would allow a clean bootup with threads
starting out on the specific processors we want them to.

Also there is even more work ahead to deal with things like kswapd,
writeback threads, compaction and various other scanners that should also
be restricted. Mostly one thread per node is sufficient. This is not
simple to do from user space.



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