linux-kernel - Re: 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-prev] [day] [month] [year] [list]

Date:	Thu, 5 May 2016 10:45:37 +0800
From:	Wanpeng Li <kernellwp@...il.com>
To:	"Grochowalski, Matthew (GE Aviation, US)" 
	<MatthewS.Grochowalski@...com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"parri.andrea@...il.com" <parri.andrea@...il.com>,
	"libc-alpha@...rceware.org" <libc-alpha@...rceware.org>
Subject: Re: sched: Where to queue RT tasks on prio drop

2016-05-05 4:51 GMT+08:00 Grochowalski, Matthew (GE Aviation, US)
<MatthewS.Grochowalski@...com>:
> 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 this is almost follow 7, right?

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



-- 
Regards,
Wanpeng Li