[Ksummit-2012-discuss] debug options.

Dave Jones davej at redhat.com
Wed Jun 27 15:53:47 UTC 2012


Something else I'd like to talk about.

We have boatloads of config options for debugging features.
Sometimes it feels like hardly anyone is using them.

* We have code that manages to get all the way through a cycle of -next,
  land in Linus' tree, and then people start noticing "hey, lockdep triggers"
  or "slab corruption" or..
  Is this just insufficient people testing -next ?
  No-one using debug options when testing -next ?
  Some of these bugs are of course hardware/setup specific, but I'm sure a lot
  of them are just "oh, that option slows things down, I never use it".
  How can we improve coverage testing here ?

* 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.

* 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).

  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 ?


	Dave


[*] hello.


More information about the Ksummit-2012-discuss mailing list