Re: [PATCH] sched_ext: Fix build errors and unused label warning in non-cgroup configs

Re: [PATCH] sched_ext: Fix build errors and unused label warning in non-cgroup configs

[Tejun Heo]

Hello,

On Sat, Mar 21, 2026 at 03:35:20PM +0100, Andrea Righi wrote:
> This looks like a false positive, the kernel test robot likely tested
> with a manually crafted config, so I think we shouldn't apply this
> patch.

It's not a false positive. CONFIG_SCHED_CLASS_EXT doesn't depend on
CONFIG_CGROUPS in Kconfig, so SCHED_CLASS_EXT=y with CGROUPS=n is a
valid config. I reproduced the build failure using the bot's config.

The issue is that CONFIG_EXT_SUB_SCHED is def_bool y depending only on
SCHED_CLASS_EXT, so it's always on. But EXT_SUB_SCHED fundamentally
needs cgroups (cgroup_path, cgroup_get, cgroup_put, cgroup_id, etc.),
so the missing dependency is there.

Cheng-Yang, can you send a v2 with the following approach?

1. Add CGROUPS dependency to EXT_SUB_SCHED in init/Kconfig:

    config EXT_SUB_SCHED
            def_bool y
   -        depends on SCHED_CLASS_EXT
   +        depends on SCHED_CLASS_EXT && CGROUPS

2. Guard err_stop_helper with #ifdef CONFIG_EXT_SUB_SCHED (only
   jumped to from within CONFIG_EXT_SUB_SCHED code):

   +#ifdef CONFIG_EXT_SUB_SCHED
    err_stop_helper:
            kthread_destroy_worker(sch->helper);
   +#endif
    err_free_pcpu:

3. Guard cgroup_get/cgroup_put in common paths with the existing
   CONFIG_EXT_GROUP_SCHED || CONFIG_EXT_SUB_SCHED pattern (matching
   the root_cgroup() / sch_cgroup() stubs):

    err_put_cgrp:
   +#if defined(CONFIG_EXT_GROUP_SCHED) || defined(CONFIG_EXT_SUB_SCHED)
            cgroup_put(cgrp);
   +#endif

   and:

   +#if defined(CONFIG_EXT_GROUP_SCHED) || defined(CONFIG_EXT_SUB_SCHED)
            cgroup_get(cgrp);
   +#endif
            sch = scx_alloc_and_add_sched(ops, cgrp, NULL);

I verified this builds clean with both CGROUPS=y and CGROUPS=n.

Thanks.

--
tejun

Re: [PATCH] sched_ext: Fix build errors and unused label warning in non-cgroup configs

[Andrea Righi]

Hi,

On Sat, Mar 21, 2026 at 09:10:03AM -1000, Tejun Heo wrote:
> Hello,
> 
> On Sat, Mar 21, 2026 at 03:35:20PM +0100, Andrea Righi wrote:
> > This looks like a false positive, the kernel test robot likely tested
> > with a manually crafted config, so I think we shouldn't apply this
> > patch.
> 
> It's not a false positive. CONFIG_SCHED_CLASS_EXT doesn't depend on
> CONFIG_CGROUPS in Kconfig, so SCHED_CLASS_EXT=y with CGROUPS=n is a
> valid config. I reproduced the build failure using the bot's config.
> 
> The issue is that CONFIG_EXT_SUB_SCHED is def_bool y depending only on
> SCHED_CLASS_EXT, so it's always on. But EXT_SUB_SCHED fundamentally
> needs cgroups (cgroup_path, cgroup_get, cgroup_put, cgroup_id, etc.),
> so the missing dependency is there.

Ah you guys are right! I was assuming that you can't have
CONFIG_SCHED_CLASS_EXT=y and CONFIG_CGROUPS=n, but that's just wrong.

So ignore my comment and sorry for the noise.

> 
> Cheng-Yang, can you send a v2 with the following approach?
> 
> 1. Add CGROUPS dependency to EXT_SUB_SCHED in init/Kconfig:
> 
>     config EXT_SUB_SCHED
>             def_bool y
>    -        depends on SCHED_CLASS_EXT
>    +        depends on SCHED_CLASS_EXT && CGROUPS
> 
> 2. Guard err_stop_helper with #ifdef CONFIG_EXT_SUB_SCHED (only
>    jumped to from within CONFIG_EXT_SUB_SCHED code):
> 
>    +#ifdef CONFIG_EXT_SUB_SCHED
>     err_stop_helper:
>             kthread_destroy_worker(sch->helper);
>    +#endif
>     err_free_pcpu:
> 
> 3. Guard cgroup_get/cgroup_put in common paths with the existing
>    CONFIG_EXT_GROUP_SCHED || CONFIG_EXT_SUB_SCHED pattern (matching
>    the root_cgroup() / sch_cgroup() stubs):
> 
>     err_put_cgrp:
>    +#if defined(CONFIG_EXT_GROUP_SCHED) || defined(CONFIG_EXT_SUB_SCHED)
>             cgroup_put(cgrp);
>    +#endif
> 
>    and:
> 
>    +#if defined(CONFIG_EXT_GROUP_SCHED) || defined(CONFIG_EXT_SUB_SCHED)
>             cgroup_get(cgrp);
>    +#endif
>             sch = scx_alloc_and_add_sched(ops, cgrp, NULL);
> 
> I verified this builds clean with both CGROUPS=y and CGROUPS=n.

And this looks good also on my side.

Thanks,
-Andrea

Re: [PATCH] sched_ext: Fix build errors and unused label warning in non-cgroup configs

[Cheng-Yang Chou]

Hi Tejun,

On Sat, Mar 21, 2026 at 09:10:03AM -1000, Tejun Heo wrote:
> Hello,
> 
> On Sat, Mar 21, 2026 at 03:35:20PM +0100, Andrea Righi wrote:
> > This looks like a false positive, the kernel test robot likely tested
> > with a manually crafted config, so I think we shouldn't apply this
> > patch.
> 
> It's not a false positive. CONFIG_SCHED_CLASS_EXT doesn't depend on
> CONFIG_CGROUPS in Kconfig, so SCHED_CLASS_EXT=y with CGROUPS=n is a
> valid config. I reproduced the build failure using the bot's config.
> 
> The issue is that CONFIG_EXT_SUB_SCHED is def_bool y depending only on
> SCHED_CLASS_EXT, so it's always on. But EXT_SUB_SCHED fundamentally
> needs cgroups (cgroup_path, cgroup_get, cgroup_put, cgroup_id, etc.),
> so the missing dependency is there.
> 
> Cheng-Yang, can you send a v2 with the following approach?
> 
> 1. Add CGROUPS dependency to EXT_SUB_SCHED in init/Kconfig:
> 
>     config EXT_SUB_SCHED
>             def_bool y
>    -        depends on SCHED_CLASS_EXT
>    +        depends on SCHED_CLASS_EXT && CGROUPS
> 
> 2. Guard err_stop_helper with #ifdef CONFIG_EXT_SUB_SCHED (only
>    jumped to from within CONFIG_EXT_SUB_SCHED code):
> 
>    +#ifdef CONFIG_EXT_SUB_SCHED
>     err_stop_helper:
>             kthread_destroy_worker(sch->helper);
>    +#endif
>     err_free_pcpu:
> 
> 3. Guard cgroup_get/cgroup_put in common paths with the existing
>    CONFIG_EXT_GROUP_SCHED || CONFIG_EXT_SUB_SCHED pattern (matching
>    the root_cgroup() / sch_cgroup() stubs):
> 
>     err_put_cgrp:
>    +#if defined(CONFIG_EXT_GROUP_SCHED) || defined(CONFIG_EXT_SUB_SCHED)
>             cgroup_put(cgrp);
>    +#endif
> 
>    and:
> 
>    +#if defined(CONFIG_EXT_GROUP_SCHED) || defined(CONFIG_EXT_SUB_SCHED)
>             cgroup_get(cgrp);
>    +#endif
>             sch = scx_alloc_and_add_sched(ops, cgrp, NULL);
> 
> I verified this builds clean with both CGROUPS=y and CGROUPS=n.
> 
> Thanks.
> 
> --
> tejun

I have sent a v2 patch.
Thanks for explaining the dependency issue!

Link to v2:
https://lore.kernel.org/r/20260322063955.951848-1-yphbchou0911@gmail.com/

-- 
Thanks,
Cheng-Yang