[Ksummit-2012-discuss] debug options.

[Jan Kara]

On Wed 27-06-12 11:53:47, Dave Jones wrote:
> 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 ?
  Well, there are two sides to this - when you run with debug options you
may hit different code paths than without them. Thus you won't see bugs
people will see without debug options. Especially if you care about things
like lock contention or other performance issues.

BTW: I do test my trees with lockdep and slab debug enabled...

> * 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.
  For example for radix trees there is a reasonable test harness in
userspace (Andrew is maintaining it). I'm not sure if that bug got though
simply because noone run the tests or if the test harness didn't check for
the right thing...

That radix tree tests take some time to run (like tens of seconds) so I'm
sceptical someone would enable them in kernel config except really
determined individuals. But including the tests in kernel tree so that it's
easier for determined individuals (and developers changing radix tree code)
to run them would be a good thing IMHO.

								Honza
-- 
Jan Kara <jack at suse.cz>
SUSE Labs, CR