linux-kernel - sched: Where to queue RT tasks on prio drop

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-next>] [day] [month] [year] [list]

Message-ID: <4F5135A853DDCC4BAAF325E04E1419C8077E8C46@ALPMBAPA10.e2k.ad.ge.com>
Date:	Wed, 4 May 2016 20:51:24 +0000
From:	"Grochowalski, Matthew (GE Aviation, US)" 
	<MatthewS.Grochowalski@...com>
To:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:	"tglx@...utronix.de" <tglx@...utronix.de>,
	"parri.andrea@...il.com" <parri.andrea@...il.com>,
	"libc-alpha@...rceware.org" <libc-alpha@...rceware.org>
Subject: sched: Where to queue RT tasks on prio drop

It looks like commit 81a44c5 (sched: Queue RT tasks to head when prio drop) made the behavior on dropping (userspace view) more sensible but I believe the behavior is still incorrect according to POSIX.

POSIX (in volume 2 section 2.8.4 Process Scheduling) specifies two different semantics for where the task is placed in the thread list for the new priority

8. If a thread whose policy or priority has been modified by pthread_setschedprio() is a running thread or is runnable, the effect on its position in the thread list depends on the direction of the modification, as follows:
	a. If the priority is raised, the thread becomes the tail of the thread list.
	b. If the priority is unchanged, the thread does not change position in the thread list.
	c. If the priority is lowered, the thread becomes the head of the thread list.
7. If a thread whose policy or priority has been modified other than by pthread_setschedprio() is a running thread or is runnable, it then becomes the tail of the thread list for its new priority.

Commit 81a44c5 made all of the priority change functions behave according to the pthread_setschedprio semantics.

It appears commit ff77e46 (sched/rt: Fix PI handling vs. sched_setscheduler()) causes changing a task's priority to its existing priority to requeue it at the tail. 
So a task settings its own priority to its current priority would be the same as a sched_yield().

I believe the correct behavior is to have the existing priority change syscalls (sched_setscheduler and sched_setparam) always move the changed task to the back of the queue for the new priority.

But as far as I can tell the kernel provides no way to implement pthread_setschedprio with the correct semantics.

It seems the best way to implement this would be adding a flag (SCHED_SETSCHEDPRIO) to the existing sched_setattr syscall. 

Any thoughts?

Thanks,
--Matt Grochowalski