According to Documentation: * sched_rt_period_us takes values from 1 to INT_MAX.
There is even check for this in sched_rt_global_validate(), but it doesn't work because sysctl_sched_rt_period is unsigned int. One could have an impression that check for negative values works, but it's only because it's not possible to set global limit lower than cgroup limit and "-1" will simply result in very low runtime to period ratio. It's still possible to set sched_rt_runtime_us to "-1" and then set sched_rt_period_us to "-1". Let's change the type of sysctl_sched_rt_period to signed int, because sched_rt_handler() uses proc_dointvec() to assign this variable and global_rt_period() anyway converts it to u64. After this change it's not possible to assign negative values to sched_rt_period_us any more. Signed-off-by: Alexander Sverdlin <alexander.sverd...@nokia.com> Reported-by: Vivenzio Pagliari <vivenzio.pagli...@nokia.com> --- include/linux/sched/sysctl.h | 2 +- kernel/sched/core.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/sched/sysctl.h b/include/linux/sched/sysctl.h index 596a0e0..5d58dbb 100644 --- a/include/linux/sched/sysctl.h +++ b/include/linux/sched/sysctl.h @@ -82,7 +82,7 @@ static inline unsigned int get_sysctl_timer_migration(void) * /proc/sys/kernel/sched_rt_period_us * /proc/sys/kernel/sched_rt_runtime_us */ -extern unsigned int sysctl_sched_rt_period; +extern int sysctl_sched_rt_period; extern int sysctl_sched_rt_runtime; #ifdef CONFIG_CFS_BANDWIDTH diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 1236732..7dda0cc 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -296,7 +296,7 @@ const_debug unsigned int sysctl_sched_time_avg = MSEC_PER_SEC; * period over which we measure -rt task cpu usage in us. * default: 1s */ -unsigned int sysctl_sched_rt_period = 1000000; +int sysctl_sched_rt_period = 1000000; __read_mostly int scheduler_running; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
