linux-kernel - Re: SCHED_DEADLINE, sched_getscheduler(), and 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]

Date:	Mon, 12 May 2014 21:42:44 +0200
From:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	mtk.manpages@...il.com, Juri Lelli <juri.lelli@...il.com>,
	Dario Faggioli <raistlin@...ux.it>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-man <linux-man@...r.kernel.org>
Subject: Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam()

On 05/12/2014 05:25 PM, Peter Zijlstra wrote:
> On Mon, May 12, 2014 at 02:33:42PM +0200, Michael Kerrisk (man-pages) wrote:
>>> I'm a proponent of fail hard instead of fail silently and muddle on.
>>> And while we can fully and correctly return sched_getscheduler() we
>>> cannot do so for sched_getparam().
>>>
>>> Returning sched_param::sched_priority == 0 for DEADLINE would also break
>>> the symmetry between sched_setparam() and sched_getparam(), both will
>>> fail for SCHED_DEADLINE.
>>
>> Maybe. But there seems to me to be a problem with your logic here.
>> (And the symmetry argument seems a weak one to me.)
>>
>> I mean, applications that are currently using sched_getscheduler()
>> will now get back a new policy (SCHED_DEADLINE) that they may not
>> understand, and so they may break.
>>
>> On the other hand, applications that call sched_getparam() will fail
>> with EINVAL, even though sched_priority has no meaning for
>> SCHED_DEADLINE (as for the non-real-time policies), and so it would
>> seem to be harmless to succeed and return a sched_priority of 0 in
>> this case. It seems to break user-space needlessly, IMHO.
>>
>> If anything, I'd have said it would have made more sense to have the
>> sched_getscheduler() case fail, while having the sched_getparam() case
>> succeed. (But, I can see the argument for having _both_ cases
>> succeed.)
> 
> Hmm,.. maybe. Can we still change this? Again, maybe, there's not really
> that much userspace that relies on this.

I think the sched_getparam() change is worthwhile (and the patches 
could (should?) be marked for -stable). I suspect there's no user
space that relies on the current SCHED_DEADLINE behavior, and it's 
worth avoiding the above breakage for sched_getparam(). I'd be 
inclined to leave sched_getscheduler() as is: there's arguments 
either way for how it should behave.

> In any case, the way I read the little there is on getparam() it seems
> to imply the only case where it does make sense to call it at all is
> when sched_getscheduler() returns either SCHED_FIFO or SCHED_RR.

(Yes, that's my understanding too.)

> And in that sense I suppose the precedent for all other currently
> available classes to not fail the param call but return 0 should be
> extended.

Yes.

> If only we'd started out with sched_yield()/sched_getparam() etc failing
> when not !SCHED_FIFO/RR :-)

Here, I think we're just following POSIX.

Cheers,

Michael

 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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/