linux-kernel - Re: [PATCH RESEND 2 1/1] sched/syscalls: Allow setting niceness using 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]

Message-ID: <20241113095816.6ed4cefd@gandalf.local.home>
Date: Wed, 13 Nov 2024 09:58:16 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Michael Pratt <mcpratt@...me>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Andrew Morton
 <akpm@...ux-foundation.org>, Thomas Gleixner <tglx@...utronix.de>, Peter
 Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, Juri Lelli
 <juri.lelli@...hat.com>, Vincent Guittot <vincent.guittot@...aro.org>,
 Dietmar Eggemann <dietmar.eggemann@....com>, Ben Segall
 <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>, Valentin Schneider
 <vschneid@...hat.com>, linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH RESEND 2 1/1] sched/syscalls: Allow setting niceness
 using sched_param struct

On Wed, 13 Nov 2024 06:04:59 +0000
Michael Pratt <mcpratt@...me> wrote:

> > $ man sched_setscheduler
> > [..]
> > SCHED_OTHER the standard round-robin time-sharing policy;
> > 
> > SCHED_BATCH for "batch" style execution of processes; and
> > 
> > SCHED_IDLE for running very low priority background jobs.
> > 
> > For each of the above policies, param->sched_priority must be 0.
> > 
> > 
> > Where we already document that the sched_priority "must be 0".  
> 
> I think we should all agree that documentation is a summary of development,
> not the other way around. Not only that, but this is poor documentation.
> The kernel is subject to change, imagine using the word "always"
> for design decisions that are not standardized.
> A more appropriate description would be
> "for each policy, sched_priority must be within the range
> provided by the return of [the query system calls]"
> just as POSIX describes the relationship.
> 
> As far as I can see, the "must be 0" requirement is completely arbitrary,
> or, if there is a reason, it must be a fairly poor one.
> However, I do recognize that the actual static priority cannot change,
> hence the adjustment to niceness instead is the obvious intention
> to any attempt to adjust the priority on the kernel-side from userspace.
> 
> I consider this patch to be a fix for a design decision
> that makes no sense when reading about the intended purpose
> of these values, not that it's the only way to achieve the priority adjustment.
> If anyone considers that something this simple should have been done already,
> the fact that documentation would have to be adjusted should not block it.
> Besides, a well-written program would already have been using
> the functions that return the accepted range before executing
> the sched_setscheduler() system call with a value that would be rejected.
> 
> Am I really the only one to read that you can't set the priority
> with this system call when I can do it on the command line with the "nice" program
> which uses a different system call, and ask "what's the point of this restriction?"

Honestly, I would actually prefer your change. But modifying an existing
API is above my pay grade ;-)   I think you really need Linus to answer that.

Linus?

-- Steve