2022-03-18 08:07:34

by Baisong Zhong

[permalink] [raw]
Subject: [PATCH -next] sched/rt: fix build error when CONFIG_SYSCTL is disable

Avoid random build errors which do not select
CONFIG_SYSCTL by depending on it in Kconfig.

This fixes the following warning:

In file included from kernel/sched/build_policy.c:43:
At top level:
kernel/sched/rt.c:3017:12: error: ‘sched_rr_handler’ defined but not used [-Werror=unused-function]
3017 | static int sched_rr_handler(struct ctl_table *table, int write, void *buffer,
| ^~~~~~~~~~~~~~~~
kernel/sched/rt.c:2978:12: error: ‘sched_rt_handler’ defined but not used [-Werror=unused-function]
2978 | static int sched_rt_handler(struct ctl_table *table, int write, void *buffer,
| ^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[2]: *** [scripts/Makefile.build:310: kernel/sched/build_policy.o] Error 1
make[1]: *** [scripts/Makefile.build:638: kernel/sched] Error 2
make[1]: *** Waiting for unfinished jobs....

Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Baisong Zhong <[email protected]>
---
kernel/sched/rt.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 71791be36065..ee319581b1cd 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -5,7 +5,6 @@
*/

int sched_rr_timeslice = RR_TIMESLICE;
-static int sysctl_sched_rr_timeslice = (MSEC_PER_SEC / HZ) * RR_TIMESLICE;
/* More than 4 hours if BW_SHIFT equals 20. */
static const u64 max_rt_runtime = MAX_BW;

@@ -25,11 +24,12 @@ unsigned int sysctl_sched_rt_period = 1000000;
*/
int sysctl_sched_rt_runtime = 950000;

+#ifdef CONFIG_SYSCTL
+static int sysctl_sched_rr_timeslice = (MSEC_PER_SEC / HZ) * RR_TIMESLICE;
static int sched_rt_handler(struct ctl_table *table, int write, void *buffer,
size_t *lenp, loff_t *ppos);
static int sched_rr_handler(struct ctl_table *table, int write, void *buffer,
size_t *lenp, loff_t *ppos);
-#ifdef CONFIG_SYSCTL
static struct ctl_table sched_rt_sysctls[] = {
{
.procname = "sched_rt_period_us",
@@ -2911,6 +2911,7 @@ long sched_group_rt_period(struct task_group *tg)
return rt_period_us;
}

+#ifdef CONFIG_SYSCTL
static int sched_rt_global_constraints(void)
{
int ret = 0;
@@ -2930,8 +2931,11 @@ int sched_rt_can_attach(struct task_group *tg, struct task_struct *tsk)

return 1;
}
+#endif /* CONFIG_SYSCTL */

#else /* !CONFIG_RT_GROUP_SCHED */
+
+#ifdef CONFIG_SYSCTL
static int sched_rt_global_constraints(void)
{
unsigned long flags;
@@ -2949,8 +2953,10 @@ static int sched_rt_global_constraints(void)

return 0;
}
+#endif /* CONFIG_SYSCTL */
#endif /* CONFIG_RT_GROUP_SCHED */

+#ifdef CONFIG_SYSCTL
static int sched_rt_global_validate(void)
{
if (sysctl_sched_rt_period <= 0)
@@ -3035,6 +3041,7 @@ static int sched_rr_handler(struct ctl_table *table, int write, void *buffer,

return ret;
}
+#endif /* CONFIG_SYSCTL */

#ifdef CONFIG_SCHED_DEBUG
void print_rt_stats(struct seq_file *m, int cpu)
--
2.25.1


2022-03-18 09:13:38

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH -next] sched/rt: fix build error when CONFIG_SYSCTL is disable


I believe these build errors are caused by new commits in the sysctl-next
tree that change scheduler code:

4925401d06dc sched: Move rr_timeslice sysctls to rt.c
5f6e55c2485c sched: Move rt_period/runtime sysctls to rt.c

In particular I don't see any Cc: to scheduler folks in these two commits -
and I'd have preferred to pick these up into the scheduler tree, to avoid
the merge conflicts and the build failure regressions...

Thanks,

Ingo


* Baisong Zhong <[email protected]> wrote:

> Avoid random build errors which do not select
> CONFIG_SYSCTL by depending on it in Kconfig.
>
> This fixes the following warning:
>
> In file included from kernel/sched/build_policy.c:43:
> At top level:
> kernel/sched/rt.c:3017:12: error: ‘sched_rr_handler’ defined but not used [-Werror=unused-function]
> 3017 | static int sched_rr_handler(struct ctl_table *table, int write, void *buffer,
> | ^~~~~~~~~~~~~~~~
> kernel/sched/rt.c:2978:12: error: ‘sched_rt_handler’ defined but not used [-Werror=unused-function]
> 2978 | static int sched_rt_handler(struct ctl_table *table, int write, void *buffer,
> | ^~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
> make[2]: *** [scripts/Makefile.build:310: kernel/sched/build_policy.o] Error 1
> make[1]: *** [scripts/Makefile.build:638: kernel/sched] Error 2
> make[1]: *** Waiting for unfinished jobs....
>
> Reported-by: Hulk Robot <[email protected]>
> Signed-off-by: Baisong Zhong <[email protected]>
> ---
> kernel/sched/rt.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
> index 71791be36065..ee319581b1cd 100644
> --- a/kernel/sched/rt.c
> +++ b/kernel/sched/rt.c
> @@ -5,7 +5,6 @@
> */
>
> int sched_rr_timeslice = RR_TIMESLICE;
> -static int sysctl_sched_rr_timeslice = (MSEC_PER_SEC / HZ) * RR_TIMESLICE;
> /* More than 4 hours if BW_SHIFT equals 20. */
> static const u64 max_rt_runtime = MAX_BW;
>
> @@ -25,11 +24,12 @@ unsigned int sysctl_sched_rt_period = 1000000;
> */
> int sysctl_sched_rt_runtime = 950000;
>
> +#ifdef CONFIG_SYSCTL
> +static int sysctl_sched_rr_timeslice = (MSEC_PER_SEC / HZ) * RR_TIMESLICE;
> static int sched_rt_handler(struct ctl_table *table, int write, void *buffer,
> size_t *lenp, loff_t *ppos);
> static int sched_rr_handler(struct ctl_table *table, int write, void *buffer,
> size_t *lenp, loff_t *ppos);
> -#ifdef CONFIG_SYSCTL
> static struct ctl_table sched_rt_sysctls[] = {
> {
> .procname = "sched_rt_period_us",
> @@ -2911,6 +2911,7 @@ long sched_group_rt_period(struct task_group *tg)
> return rt_period_us;
> }
>
> +#ifdef CONFIG_SYSCTL
> static int sched_rt_global_constraints(void)
> {
> int ret = 0;
> @@ -2930,8 +2931,11 @@ int sched_rt_can_attach(struct task_group *tg, struct task_struct *tsk)
>
> return 1;
> }
> +#endif /* CONFIG_SYSCTL */
>
> #else /* !CONFIG_RT_GROUP_SCHED */
> +
> +#ifdef CONFIG_SYSCTL
> static int sched_rt_global_constraints(void)
> {
> unsigned long flags;
> @@ -2949,8 +2953,10 @@ static int sched_rt_global_constraints(void)
>
> return 0;
> }
> +#endif /* CONFIG_SYSCTL */
> #endif /* CONFIG_RT_GROUP_SCHED */
>
> +#ifdef CONFIG_SYSCTL
> static int sched_rt_global_validate(void)
> {
> if (sysctl_sched_rt_period <= 0)
> @@ -3035,6 +3041,7 @@ static int sched_rr_handler(struct ctl_table *table, int write, void *buffer,
>
> return ret;
> }
> +#endif /* CONFIG_SYSCTL */
>
> #ifdef CONFIG_SCHED_DEBUG
> void print_rt_stats(struct seq_file *m, int cpu)
> --
> 2.25.1
>

2022-03-21 13:04:08

by Luis Chamberlain

[permalink] [raw]
Subject: Re: [PATCH -next] sched/rt: fix build error when CONFIG_SYSCTL is disable

On Fri, Mar 18, 2022 at 08:50:50AM +0100, Ingo Molnar wrote:
>
> I believe these build errors are caused by new commits in the sysctl-next
> tree that change scheduler code:
>
> 4925401d06dc sched: Move rr_timeslice sysctls to rt.c
> 5f6e55c2485c sched: Move rt_period/runtime sysctls to rt.c
>
> In particular I don't see any Cc: to scheduler folks in these two commits -
> and I'd have preferred to pick these up into the scheduler tree, to avoid
> the merge conflicts and the build failure regressions...

Sorry about that, Peter was Cc'd on the patches and he did provide
feedback on the first set. During that review I also had suggested that
since it seemed that during the new kernel development cycle the next
target was sched for sysctl moves out of kernel/sysctl.c *but* that since
Andrew had merged these during the last kernel release I had suggested
to Peter that perhaps these should just go through his tree [0]. No
was no replies to that thread.

I had provided feedack for Zhen Ni's 2nd series of his patches and I
also had suggested for him to use 0day to avoid build issues. By his
3rd spin it was already on my radar that more syctls changes were being
posted outside of sched and so I asked for feedback from Andrew / Peter
about using instead a dedicated tree to collect sysctl changes to avoid
possible merge conflicts [1]. The only replies came from Andrew agreeing
to a syctl-next tree to help to avoid merge conflicts [2]. By v3 then,
through feedback by Andrew and no replies by Peter I decided to take this
via sysctl-next and let these get baked / tested through linux-next and
0day.

Let me know if you'd like me to drop these patches and rebase my tree,
or if you'd like to proceed some other way.

[0] https://lkml.kernel.org/r/[email protected]
[1] https://lkml.kernel.org/r/[email protected]
[2] https://lkml.kernel.org/r/Yg/jxFqiuyR/[email protected]

Luis