On Sun, Jan 3, 2021 at 5:14 AM Valdis Klētnieks <valdis.kletnieks@xxxxxx> wrote:
>
> Consider the following own goal I just discovered I scored:
>
> [~] zgrep -i fq_codel /proc/config.gz
> CONFIG_NET_SCH_FQ_CODEL=m
> CONFIG_DEFAULT_FQ_CODEL=y
> CONFIG_DEFAULT_NET_SCH="fq_codel"
>
> Obviously, fq_codel didn't get set as the default, because that happens
> before the module gets loaded (which may never happen if the sysadmin
> thinks the DEFAULT_NET_SCH already made it happen)
>
> Whoops. My bad, probably - but....
>
> The deeper question, part 1:
>
> There's this chunk in net/sched/Kconfig:
>
> config DEFAULT_NET_SCH
> string
> default "pfifo_fast" if DEFAULT_PFIFO_FAST
> default "fq" if DEFAULT_FQ
> default "fq_codel" if DEFAULT_FQ_CODEL
> default "fq_pie" if DEFAULT_FQ_PIE
> default "sfq" if DEFAULT_SFQ
> default "pfifo_fast"
> endif
>
> (And a similar chunk right above it with a similar issue)
>
> Should those be "if (foo=y)" so =m can't be chosen? (I'll be
> happy to write the patch if that's what we want)
>
> Deeper question, part 2:
>
> Should there be a way in the Kconfig language to ensure that
> these two chunks can't accidentally get out of sync? There's other
> places in the kernel where similar issues arise - a few days ago I was
> chasing a CPU governor issue where it looked like it was possible
> to set a default that was a module and thus possibly not actually loaded.
>
If there is a restriction where a modular discipline cannot be the default,
I think you can add 'depends on FOO = y'.
For example,
choice
prompt "Default"
config DEFAULT_FOO
bool "Use foo for default"
depends on FOO = y
config DEFAULT_BAR
bool "Use bar for default"
depends on BAR = y
config DEFAULT_FALLBACK
bool "fallback when nothing else is builtin"
endchoice
--
Best Regards
Masahiro Yamada
