linux-kernel - Re: [PATCH] kmod: Run usermodehelpers only on cpus allowed for 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, 16 Oct 2013 22:37:52 +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 Wed, 16 Oct 2013, Andrew Morton wrote:

> > usermodehelper() threads can currently run on all processors.
> > This is an issue for low latency cores.
>
> How much of an issue?  The severity of the problem is utterly unclear
> from this description.

This causes a context switch and processing to occur. Can take up to
microseconds which is a pretty long timeframe when decisions have to be
made in microseconds by active processing. This will cause a trade to
fail.

> > -	/* We can run anywhere, unlike our parent keventd(). */
> > -	set_cpus_allowed_ptr(current, cpu_all_mask);
> > +	/* We can run anywhere kthreadd can run */
>
> This is a poor comment - it explains "what" (which was utterly obvious)
> but doesn't explain "why".  The reader will want to know *why*
> call_usermodehelper() only runs on kthreadd CPUs, but we didn't tell
> him.

We'd like to have the ability to avoid running usermodehelper on certain
cpus to avoid cpu holdoff situations? Would that we an acceptable
explanation?

Or restricting kthreadd will also restrict usermodehelper spawning to
allow control for all spawned kernel threads?



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