* SCHED_DEADLINE, sched_getscheduler(), and sched_getparam() @ 2014-05-12 12:09 ` Michael Kerrisk (man-pages) 0 siblings, 0 replies; 12+ messages in thread From: Michael Kerrisk (man-pages) @ 2014-05-12 12:09 UTC (permalink / raw) To: Peter Zijlstra Cc: Juri Lelli, Dario Faggioli, lkml, linux-man, Michael Kerrisk Hi Peter, Looking at the code of sched_getparam() and sched_setscheduler() (to see what might need to land in the man pagea with respect to SCHED_DEADLINE changes), I see that the former fails (EINVAL) if the target is a SCHED_DEADLINE process, while the latter succeeds (returning SCHED_DEADLINE). The sched_setscheduler() seems fine, but what's the rationale for having sched_getparam() fail in this case, rather than just returning a sched_priority of zero (since sched_priority is in any case unused, as for SCHED_OTHER, right)? My point is that the change seems to needlessly break applications that employ sched_getparam(). Maybe I am missing something... Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* SCHED_DEADLINE, sched_getscheduler(), and sched_getparam() @ 2014-05-12 12:09 ` Michael Kerrisk (man-pages) 0 siblings, 0 replies; 12+ messages in thread From: Michael Kerrisk (man-pages) @ 2014-05-12 12:09 UTC (permalink / raw) To: Peter Zijlstra Cc: Juri Lelli, Dario Faggioli, lkml, linux-man, Michael Kerrisk Hi Peter, Looking at the code of sched_getparam() and sched_setscheduler() (to see what might need to land in the man pagea with respect to SCHED_DEADLINE changes), I see that the former fails (EINVAL) if the target is a SCHED_DEADLINE process, while the latter succeeds (returning SCHED_DEADLINE). The sched_setscheduler() seems fine, but what's the rationale for having sched_getparam() fail in this case, rather than just returning a sched_priority of zero (since sched_priority is in any case unused, as for SCHED_OTHER, right)? My point is that the change seems to needlessly break applications that employ sched_getparam(). Maybe I am missing something... 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-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam() @ 2014-05-12 12:24 ` Peter Zijlstra 0 siblings, 0 replies; 12+ messages in thread From: Peter Zijlstra @ 2014-05-12 12:24 UTC (permalink / raw) To: Michael Kerrisk (man-pages); +Cc: Juri Lelli, Dario Faggioli, lkml, linux-man On Mon, May 12, 2014 at 02:09:58PM +0200, Michael Kerrisk (man-pages) wrote: > Hi Peter, > > Looking at the code of sched_getparam() and sched_setscheduler() (to > see what might need to land in the man pagea with respect to > SCHED_DEADLINE changes), I see that the former fails (EINVAL) if the > target is a SCHED_DEADLINE process, while the latter succeeds > (returning SCHED_DEADLINE). > > The sched_setscheduler() seems fine, but what's the rationale for > having sched_getparam() fail in this case, rather than just returning > a sched_priority of zero (since sched_priority is in any case unused, > as for SCHED_OTHER, right)? My point is that the change seems to > needlessly break applications that employ sched_getparam(). Maybe I am > missing something... s/setscheduler/getscheduler/ ? 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam() @ 2014-05-12 12:24 ` Peter Zijlstra 0 siblings, 0 replies; 12+ messages in thread From: Peter Zijlstra @ 2014-05-12 12:24 UTC (permalink / raw) To: Michael Kerrisk (man-pages); +Cc: Juri Lelli, Dario Faggioli, lkml, linux-man On Mon, May 12, 2014 at 02:09:58PM +0200, Michael Kerrisk (man-pages) wrote: > Hi Peter, > > Looking at the code of sched_getparam() and sched_setscheduler() (to > see what might need to land in the man pagea with respect to > SCHED_DEADLINE changes), I see that the former fails (EINVAL) if the > target is a SCHED_DEADLINE process, while the latter succeeds > (returning SCHED_DEADLINE). > > The sched_setscheduler() seems fine, but what's the rationale for > having sched_getparam() fail in this case, rather than just returning > a sched_priority of zero (since sched_priority is in any case unused, > as for SCHED_OTHER, right)? My point is that the change seems to > needlessly break applications that employ sched_getparam(). Maybe I am > missing something... s/setscheduler/getscheduler/ ? 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. -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam() 2014-05-12 12:24 ` Peter Zijlstra (?) @ 2014-05-12 12:33 ` Michael Kerrisk (man-pages) 2014-05-12 15:25 ` Peter Zijlstra -1 siblings, 1 reply; 12+ messages in thread From: Michael Kerrisk (man-pages) @ 2014-05-12 12:33 UTC (permalink / raw) To: Peter Zijlstra; +Cc: Juri Lelli, Dario Faggioli, lkml, linux-man On Mon, May 12, 2014 at 2:24 PM, Peter Zijlstra <peterz@infradead.org> wrote: > On Mon, May 12, 2014 at 02:09:58PM +0200, Michael Kerrisk (man-pages) wrote: >> Hi Peter, >> >> Looking at the code of sched_getparam() and sched_setscheduler() (to >> see what might need to land in the man pagea with respect to >> SCHED_DEADLINE changes), I see that the former fails (EINVAL) if the >> target is a SCHED_DEADLINE process, while the latter succeeds >> (returning SCHED_DEADLINE). >> >> The sched_setscheduler() seems fine, but what's the rationale for >> having sched_getparam() fail in this case, rather than just returning >> a sched_priority of zero (since sched_priority is in any case unused, >> as for SCHED_OTHER, right)? My point is that the change seems to >> needlessly break applications that employ sched_getparam(). Maybe I am >> missing something... > > s/setscheduler/getscheduler/ ? Yes, sorry. > 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.) Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam() 2014-05-12 12:33 ` Michael Kerrisk (man-pages) @ 2014-05-12 15:25 ` Peter Zijlstra 2014-05-12 19:42 ` Michael Kerrisk (man-pages) 0 siblings, 1 reply; 12+ messages in thread From: Peter Zijlstra @ 2014-05-12 15:25 UTC (permalink / raw) To: Michael Kerrisk (man-pages); +Cc: Juri Lelli, Dario Faggioli, lkml, linux-man [-- Attachment #1: Type: text/plain, Size: 1913 bytes --] 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. 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. 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. If only we'd started out with sched_yield()/sched_getparam() etc failing when not !SCHED_FIFO/RR :-) [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam() @ 2014-05-12 19:42 ` Michael Kerrisk (man-pages) 0 siblings, 0 replies; 12+ messages in thread From: Michael Kerrisk (man-pages) @ 2014-05-12 19:42 UTC (permalink / raw) To: Peter Zijlstra; +Cc: mtk.manpages, Juri Lelli, Dario Faggioli, lkml, linux-man 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam() @ 2014-05-12 19:42 ` Michael Kerrisk (man-pages) 0 siblings, 0 replies; 12+ messages in thread From: Michael Kerrisk (man-pages) @ 2014-05-12 19:42 UTC (permalink / raw) To: Peter Zijlstra Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, Juri Lelli, Dario Faggioli, lkml, linux-man 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-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam() @ 2014-05-12 20:50 ` Peter Zijlstra 0 siblings, 0 replies; 12+ messages in thread From: Peter Zijlstra @ 2014-05-12 20:50 UTC (permalink / raw) To: Michael Kerrisk (man-pages); +Cc: Juri Lelli, Dario Faggioli, lkml, linux-man On Mon, May 12, 2014 at 09:42:44PM +0200, Michael Kerrisk (man-pages) wrote: > > 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.) Something like so then, it encodes that reading explicitly. --- Subject: sched: Change sched_getparam() behaviour vs SCHED_DEADLINE From: Peter Zijlstra <peterz@infradead.org> Date: Mon May 12 22:22:47 CEST 2014 The way we read POSIX one should only call sched_getparam() when sched_getscheduler() returns either SCHED_FIFO or SCHED_RR. Given that we currently return sched_param::sched_priority=0 for all others, extend the same behaviour to SCHED_DEADLINE. Requested-by: Michael Kerrisk <mtk.manpages@gmail.com> Signed-off-by: Peter Zijlstra <peterz@infradead.org> --- kernel/sched/core.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) Index: linux-2.6/kernel/sched/core.c =================================================================== --- linux-2.6.orig/kernel/sched/core.c +++ linux-2.6/kernel/sched/core.c @@ -3759,7 +3759,7 @@ SYSCALL_DEFINE1(sched_getscheduler, pid_ */ SYSCALL_DEFINE2(sched_getparam, pid_t, pid, struct sched_param __user *, param) { - struct sched_param lp; + struct sched_param lp = { .sched_priority = 0 }; struct task_struct *p; int retval; @@ -3776,11 +3776,8 @@ SYSCALL_DEFINE2(sched_getparam, pid_t, p if (retval) goto out_unlock; - if (task_has_dl_policy(p)) { - retval = -EINVAL; - goto out_unlock; - } - lp.sched_priority = p->rt_priority; + if (task_has_rt_policy(p)) + lp.sched_priority = p->rt_priority; rcu_read_unlock(); /* ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam() @ 2014-05-12 20:50 ` Peter Zijlstra 0 siblings, 0 replies; 12+ messages in thread From: Peter Zijlstra @ 2014-05-12 20:50 UTC (permalink / raw) To: Michael Kerrisk (man-pages); +Cc: Juri Lelli, Dario Faggioli, lkml, linux-man On Mon, May 12, 2014 at 09:42:44PM +0200, Michael Kerrisk (man-pages) wrote: > > 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.) Something like so then, it encodes that reading explicitly. --- Subject: sched: Change sched_getparam() behaviour vs SCHED_DEADLINE From: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> Date: Mon May 12 22:22:47 CEST 2014 The way we read POSIX one should only call sched_getparam() when sched_getscheduler() returns either SCHED_FIFO or SCHED_RR. Given that we currently return sched_param::sched_priority=0 for all others, extend the same behaviour to SCHED_DEADLINE. Requested-by: Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Signed-off-by: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> --- kernel/sched/core.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) Index: linux-2.6/kernel/sched/core.c =================================================================== --- linux-2.6.orig/kernel/sched/core.c +++ linux-2.6/kernel/sched/core.c @@ -3759,7 +3759,7 @@ SYSCALL_DEFINE1(sched_getscheduler, pid_ */ SYSCALL_DEFINE2(sched_getparam, pid_t, pid, struct sched_param __user *, param) { - struct sched_param lp; + struct sched_param lp = { .sched_priority = 0 }; struct task_struct *p; int retval; @@ -3776,11 +3776,8 @@ SYSCALL_DEFINE2(sched_getparam, pid_t, p if (retval) goto out_unlock; - if (task_has_dl_policy(p)) { - retval = -EINVAL; - goto out_unlock; - } - lp.sched_priority = p->rt_priority; + if (task_has_rt_policy(p)) + lp.sched_priority = p->rt_priority; rcu_read_unlock(); /* -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* [tip:sched/core] peter_zijlstra-sched-change_sched_getparam_behaviour_vs_sched_deadline 2014-05-12 20:50 ` Peter Zijlstra (?) @ 2014-05-19 13:06 ` tip-bot for Peter Zijlstra -1 siblings, 0 replies; 12+ messages in thread From: tip-bot for Peter Zijlstra @ 2014-05-19 13:06 UTC (permalink / raw) To: linux-tip-commits Cc: linux-kernel, hpa, mingo, peterz, raistlin, linux-man, tglx, mtk.manpages, juri.lelli Commit-ID: 339d8f7bbf4a54fc09650b24ce505a4c04236bb3 Gitweb: http://git.kernel.org/tip/339d8f7bbf4a54fc09650b24ce505a4c04236bb3 Author: Peter Zijlstra <peterz@infradead.org> AuthorDate: Mon, 12 May 2014 22:50:34 +0200 Committer: Thomas Gleixner <tglx@linutronix.de> CommitDate: Mon, 19 May 2014 21:47:33 +0900 peter_zijlstra-sched-change_sched_getparam_behaviour_vs_sched_deadline The way we read POSIX one should only call sched_getparam() when sched_getscheduler() returns either SCHED_FIFO or SCHED_RR. Given that we currently return sched_param::sched_priority=0 for all others, extend the same behaviour to SCHED_DEADLINE. Cc: stable@vger.kernel.org Cc: Dario Faggioli <raistlin@linux.it> Cc: linux-man <linux-man@vger.kernel.org> Cc: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> Cc: Juri Lelli <juri.lelli@gmail.com> Requested-by: Michael Kerrisk <mtk.manpages@gmail.com> Acked-by: Michael Kerrisk <mtk.manpages@gmail.com> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20140512205034.GH13467@laptop.programming.kicks-ass.net Signed-off-by: Thomas Gleixner <tglx@linutronix.de> --- kernel/sched/core.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index cdefcf7..f3f08bf 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -3713,7 +3713,7 @@ SYSCALL_DEFINE1(sched_getscheduler, pid_t, pid) */ SYSCALL_DEFINE2(sched_getparam, pid_t, pid, struct sched_param __user *, param) { - struct sched_param lp; + struct sched_param lp = { .sched_priority = 0 }; struct task_struct *p; int retval; @@ -3730,11 +3730,8 @@ SYSCALL_DEFINE2(sched_getparam, pid_t, pid, struct sched_param __user *, param) if (retval) goto out_unlock; - if (task_has_dl_policy(p)) { - retval = -EINVAL; - goto out_unlock; - } - lp.sched_priority = p->rt_priority; + if (task_has_rt_policy(p)) + lp.sched_priority = p->rt_priority; rcu_read_unlock(); /* ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [tip:sched/core] sched/deadline: Change sched_getparam() behaviour vs SCHED_DEADLINE 2014-05-12 20:50 ` Peter Zijlstra (?) (?) @ 2014-05-22 12:25 ` tip-bot for Peter Zijlstra -1 siblings, 0 replies; 12+ messages in thread From: tip-bot for Peter Zijlstra @ 2014-05-22 12:25 UTC (permalink / raw) To: linux-tip-commits Cc: linux-kernel, hpa, mingo, torvalds, peterz, stable, raistlin, linux-man, tglx, mtk.manpages, juri.lelli Commit-ID: ce5f7f8200ca2504f6f290044393d73ca314965a Gitweb: http://git.kernel.org/tip/ce5f7f8200ca2504f6f290044393d73ca314965a Author: Peter Zijlstra <peterz@infradead.org> AuthorDate: Mon, 12 May 2014 22:50:34 +0200 Committer: Ingo Molnar <mingo@kernel.org> CommitDate: Thu, 22 May 2014 10:21:26 +0200 sched/deadline: Change sched_getparam() behaviour vs SCHED_DEADLINE The way we read POSIX one should only call sched_getparam() when sched_getscheduler() returns either SCHED_FIFO or SCHED_RR. Given that we currently return sched_param::sched_priority=0 for all others, extend the same behaviour to SCHED_DEADLINE. Requested-by: Michael Kerrisk <mtk.manpages@gmail.com> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Acked-by: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Dario Faggioli <raistlin@linux.it> Cc: linux-man <linux-man@vger.kernel.org> Cc: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> Cc: Juri Lelli <juri.lelli@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/20140512205034.GH13467@laptop.programming.kicks-ass.net Signed-off-by: Ingo Molnar <mingo@kernel.org> --- kernel/sched/core.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index cdefcf7..f3f08bf 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -3713,7 +3713,7 @@ SYSCALL_DEFINE1(sched_getscheduler, pid_t, pid) */ SYSCALL_DEFINE2(sched_getparam, pid_t, pid, struct sched_param __user *, param) { - struct sched_param lp; + struct sched_param lp = { .sched_priority = 0 }; struct task_struct *p; int retval; @@ -3730,11 +3730,8 @@ SYSCALL_DEFINE2(sched_getparam, pid_t, pid, struct sched_param __user *, param) if (retval) goto out_unlock; - if (task_has_dl_policy(p)) { - retval = -EINVAL; - goto out_unlock; - } - lp.sched_priority = p->rt_priority; + if (task_has_rt_policy(p)) + lp.sched_priority = p->rt_priority; rcu_read_unlock(); /* ^ permalink raw reply related [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-05-22 12:26 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-05-12 12:09 SCHED_DEADLINE, sched_getscheduler(), and sched_getparam() Michael Kerrisk (man-pages) 2014-05-12 12:09 ` Michael Kerrisk (man-pages) 2014-05-12 12:24 ` Peter Zijlstra 2014-05-12 12:24 ` Peter Zijlstra 2014-05-12 12:33 ` Michael Kerrisk (man-pages) 2014-05-12 15:25 ` Peter Zijlstra 2014-05-12 19:42 ` Michael Kerrisk (man-pages) 2014-05-12 19:42 ` Michael Kerrisk (man-pages) 2014-05-12 20:50 ` Peter Zijlstra 2014-05-12 20:50 ` Peter Zijlstra 2014-05-19 13:06 ` [tip:sched/core] peter_zijlstra-sched-change_sched_getparam_behaviour_vs_sched_deadline tip-bot for Peter Zijlstra 2014-05-22 12:25 ` [tip:sched/core] sched/deadline: Change sched_getparam() behaviour vs SCHED_DEADLINE tip-bot for Peter Zijlstra
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.