[Ksummit-2012-discuss] debug options.

Roland Dreier roland at kernel.org
Wed Jun 27 16:08:30 UTC 2012


On Wed, Jun 27, 2012 at 8:53 AM, Dave Jones <davej at redhat.com> wrote:
> * I'd like to hear some brainstorming on potential future debug features / self-tests
>  we could add, regardless of how much performance they suck up.
>  (There's at least one crazy guy who will run all the time with it on[*])
>  Thinking of the recent radix-tree bug for eg, made me wonder..
>  - perhaps we shouldn't have self-tests for all the common data-structures the
>    kernel is using. That bug would have been caught pretty early on if the
>    kernel printed loudly RADIX TREES ARE BROKEN during bootup.
>  - I'm not familiar with how the radix tree data structure works, but runtime tests
>    like CONFIG_DEBUG_LIST for other structures may be a useful thing to catch
>    not only regressions, but also memory scribbles.

Yes, absolutely -- I think one of the only ways we can make our rarely
run code paths reliable is to have things like fault injection that make
them run more often, or memory poisoning etc that make rare bugs
more fatal.  More ideas along the lines of lockdep extensions or that
type of thing would be hugely valuable.

> * Fedora runs with the kitchen-sink of debug options on during development,
>  but even our release kernels enable some of the lower-impact options.
>  And surprise surprise, it finds stuff all the time.
>  Because we're the only distro that apparently cares about this, we get people
>  saying crazy shit like "oh, it doesn't work in Fedora, use a different distro"
>  (latest example: vmware blows up with CONFIG_DEBUG_VM, but rather than fix
>   the problem, everyone wants that stack trace to go away, and go back
>   to silently corrupting memory).

For our (Pure Storage) embedded system, we have the notion of a
"checked" kernel (stealing Windows usage, since there are already
too many things like debug symbol packages in the "dbg" namespace).
This has been really useful -- we catch tons of stuff running some
subset of tests with the checked kernel.

Perhaps distros could be nudged to offer something similar?  Some
fraction of people will run it by themselves, and bug reporters could
be nudged to try and reproduce with the checked kernel.

Of course this is most useful if we have a way of getting crash info
off the box (cf the other thread).

>  I've been toying with the idea of changing the config options for the debug options
>  to have a 'cost' associated with them, so they could depend on CONFIG_DEBUG_IMPACT_LOW
>  and so on, in the hopes that it would increase usage of these features. Thoughts ?

I suspect adding more config options is not going to help much.
Maybe having CONFIG_DEBUG_IMPACT_LOW should just enables
everything reasonably cheap -- that might get turned on.  (And hide
the sub-options in a submenu or something?)

 - R.


More information about the Ksummit-2012-discuss mailing list