linux-kernel - Re: Changing Kernel thread priorities

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, 8 Jun 2011 19:50:24 +0200
From:	Remy Bohmer <linux@...mer.net>
To:	Nicholas Mc Guire <der.herr@...r.at>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Armin Steinhoff <armin@...inhoff.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Johannes Bauer <hannes_bauer@....at>,
	Monica Puig-Pey <puigpeym@...can.es>,
	Rolando Martins <rolando.martins@...il.com>,
	linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Changing Kernel thread priorities

Hi,

>> So, in that case and in many other hotplug cases, you ruin the RT
>> behaviour of the system just by the
>> default-50-is-probably-right-assumption of the kernel.
>> For systems where you have everything under control as a user/system
>> designer, hotplug can also be under control as well.
>>
>
> I dont't quite see that - the 50 default is well dokumented so you can
> plan it into the rt design at system level. It simply means that you
> would need to put your hard-rt tasks in the range of 50<prio<99.

This is another assumption as well. You assume here that any task
bound to certain latencies must be above _all_ interrupt handlers, and
tasks not bound to certain latencies must be set below _all_ interrupt
handlers.
In fact, in real life,  the prioritisation will be much more fine
grained during runtime. One can have a RT task that depends on the
networking stack, but not on mass-storage. In that case you want to
move them out of the range of 50.
The whole idea about threaded interrupts is, is that you can give them
priorities such that they suit your specific application. It is
therefore common practice that priorities does not stay at 49/50.

In real life you may want, for EXAMPLE, this setup:
* prio 70: high priority motor control loop
* prio 60: network device irq
* prio 59: network softirqs
* prio 55: some realtime task depending on networkingstack
* prio 54: mass storage irq
* prio 53: block device softirq
* prio 52: some realtime task depending on mass-storage
* prio 50: all remaining irq threads
* prio 49: all remaining softirqs

Assume here you do a ifconfig down and ifconfig up, in the current
kernel behaviour you will see that the irq thread switches from prio
60 to 50.
The irq-thread will become of a lower priority compared to its related
softirqs due to this reason, which can result in a complete die of
this network interface... even before it ever came back up again...

As mentioned before by Thomas, the configuration is a policy issue and
must be set from user-context. I understand what he means by that and
I agree, but there still has to be a mechanism to make the kernel
remember the configuration set by the user to prevent all kinds of
race conditions. You cannot demand from the user to run after
executing a shell command like ifconfig or modprobe to run some sort
of init-script that repairs what the kernel assumed wrong. The wrong
assumptions the kernel does results in: deadlocks, priority inversion
issues between irq-threads and softirqs and realtime behaviour impact.
Even UDEV cannot_fix_this_problem_ since it runs _after_ the kernel
has set the wrong priorities of the irq threads and the problem it
imposes already may have occurred.

Setting the priorities right once is already complicated enough, it
makes it far more complex if all kinds of race conditions and
limitations need to be taken into account due to this mentioned
auto-reset-to-50(-or-1)-assumptions of the kernel...
True, there must be a safe default for booting, and 49/50 is good
enough for that.

So, you might disagree the way our patches to solve this problem are
implemented, I can buy that, it is just at the level of 'works-for-me'
. Since this discussion frequently appears back on the mailinglist
makes clear that this _is_ an issue that is relevant. Instead of
ignoring or denying this issue, we should figure out what is the
_best_way_ to solve it.
I hope to see great and constructive suggestions soon on this list, I
am very willing to implement it :-)

Kind regards,

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