lkml.org 
[lkml]   [2021]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectKconfig, DEFAULT_NETSCH, and shooting yourself in the foot..
    Date
    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.


    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2021-01-02 21:18    [W:7.170 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site