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:	Thu, 17 Oct 2013 18:24:23 +0000
From:	Christoph Lameter <cl@...ux.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Mike Galbraith <bitbucket@...ine.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Gilad Ben-Yossef <gilad@...yossef.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Mike Frysinger <vapier@...too.org>
Subject: Re: [PATCH] kmod: Run usermodehelpers only on cpus allowed for
 kthreadd

On Thu, 17 Oct 2013, Andrew Morton wrote:

> On Thu, 17 Oct 2013 18:07:28 +0200 Frederic Weisbecker <fweisbec@...il.com> wrote:
>
> > Couldn't we instead make kthread children (those created with kthread_create()) to inherit
> > kthread initial affinity? Currently kthread's children have cpu_all_mask. We could change
> > that behaviour. This way the initial kthread affinity could be inherited all along.
>
> I'm wondering if it's clean/logical to tie usermodehelper affinity to
> kthreadd affinity at all.  It's certainly convenient, but they're
> distinct concepts.  What is the reason to not have a separate control
> for usermodehelper cpus-allowed?

It was suggested in the earlier discussion. We could do it separately.

We have to limit kthreadd anyways and the idea was that the setting would
be used to limit any threads spawned that can be limited to a set of
processors.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ