Messages in this thread | | | Date | Thu, 30 Jul 2020 16:29:52 +0100 | From | Qais Yousef <> | Subject | Re: [tip:sched/fifo 44/45] ERROR: modpost: "sched_setscheduler" undefined! |
| |
On 07/29/20 12:23, Dietmar Eggemann wrote: > On 21/07/2020 12:13, Qais Yousef wrote: > > On 07/21/20 10:36, peterz@infradead.org wrote: > >> On Mon, Jul 20, 2020 at 06:19:43PM -0400, Steven Rostedt wrote: > >>> On Mon, 20 Jul 2020 23:49:18 +0200 > >>> Peter Zijlstra <peterz@infradead.org> wrote: > >>> > >>>> Steve, would this work for you, or would you prefer renaming the > >>>> parameters as well? > >>>> > >>> > >>> Yeah, that's fine. You don't have any sched_fifo_high() ? > >> > >> Thanks! and no. > >> > >> I'll go write a Changelog and add it to tip/sched/fifo, so that > >> hopefully, sfr can stop complaining about this build fail ;-) > >> > >> I've even argued we should rename fifo_low() to something else, but > >> failed to come up with a sensible name. The intended case is for when > >> you want something above normal but don't particularly care about RT at > >> all. > >> > >> The thing is, once you start adding priorities, even low,med,high, we're > >> back to where we were. And the whole argument is that the kernel cannot > >> set priorities in any sensible fashion. > > > > Agreed. I am worried about in-kernel users setting random uclamp values too. > > Do we really have to restrict in-kernel user? > > And avoiding module uclamp abuse is covered by 616d91b68cd5 ("sched: > Remove sched_setscheduler*() EXPORTs"). > > > This series should do most of the work but there are more pieces needed on-top. > > > > From what I see we still need to move the sched_setscheduler() from > > include/linux/sched.h to kernel/sched/sched.h. And sched_setattr() too. The > > latter has a single user in kernel/trace/trace_selftest.c to create a deadline > > task. I think that can be easily wrapped with a similar sched_set_dl() > > function and exported instead. > > But DL does not have the same issue like the FIFO/RR when it comes to > resource management. > Not sure if we have to restrict in-kernel user.
FWIW, I have the patches ready and tested for posting.
http://linux-arm.org/git?p=linux-qy.git;a=shortlog;h=refs/heads/sched-setscheduler-hide
Peter, do you think it's not necessary to go to that level of restriction too?
It'll just avoid surprises IMO by making sched_set{sched, attr}() static. The wrapper can be flexible to change if needed, but at least we'll know.
I addressed Paul's concern on IRC too.
Thanks
-- Qais Yousef
| |