linux-kernel - Re: [PATCH] kthread: run kthreadd with max priority SCHED

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: <20071222013021.db2528cb.akpm@linux-foundation.org>
Date:	Sat, 22 Dec 2007 01:30:21 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Michal Schmidt <mschmidt@...hat.com>
Cc:	linux-kernel@...r.kernel.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Jon Masters <jcm@...hat.com>,
	Satoru Takeuchi <takeuchi_satoru@...fujitsu.com>
Subject: Re: [PATCH] kthread: run kthreadd with max priority SCHED_FIFO

On Mon, 17 Dec 2007 23:43:14 +0100 Michal Schmidt <mschmidt@...hat.com> wrote:

> kthreadd, the creator of other kernel threads, runs as a normal
> priority task. This is a potential for priority inversion when a task
> wants to spawn a high-priority kernel thread. A middle priority
> SCHED_FIFO task can block kthreadd's execution indefinitely and thus
> prevent the timely creation of the high-priority kernel thread.
>     
> This causes a practical problem. When a runaway real-time task is
> eating 100% CPU and we attempt to put the CPU offline, sometimes we
> block while waiting for the creation of the highest-priority
> "kstopmachine" thread. 
> 
> The fix is to run kthreadd with the highest possible SCHED_FIFO
> priority. Its children must still run as slightly negatively reniced
> SCHED_NORMAL tasks.

Did you hit this problem with the stock kernel, or have you been working on
other stuff?

A locked-up SCHED_FIFO process will cause kernel threads all sorts of
problems.  You've hit one instance, but there will be others.  (pdflush
stops working, for one).

The general approach we've taken to this is "don't do that".  Yes, we could
boost lots of kernel threads in the way which this patch does but this
actually takes control *away* from userspace.  Userspace no longer has the
ability to guarantee itself minimum possible latency without getting
preempted by kernel threads.

And yes, giving userspace this minimum-latency capability does imply that
userspace has a responsibility to not 100% starve kernel threads.  It's a
reasonable compromise, I think?

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