Re: [PATCH 2/2 -mm] fault-injection: lightweight code-coverage maximizer

[Don Mullis <dwm@meer.net>]

On Wed, 2006-11-29 at 11:37 +0900, Akinobu Mita wrote:
> On Tue, Nov 28, 2006 at 12:14:36PM -0800, Don Mullis wrote:
> > First, waiting a few seconds for the standard FC-6 daemons to wake up.
> > Then, Xemacs and Firefox.  Not tested on SMP.
> 
> Is it failslab or fail_page_alloc ?

Usually failslab, as it exposes unique stacks more quickly.

> > > This doesn't maximize code coverage. It makes fault-injector reject
> > > any failures which have same stacktrace before.
> > 
> > Since the volume of (repeated) dumps is greatly reduced, 
> > interval/probability can be set more aggressively without crippling
> > interaction.  This increases the number of error recovery paths covered
> > per unit of wall clock time.
> > 
> It seems artificial. Injecting failures into slab or page allocator causes
> vastly greater range of errors and it should be. I feel what you really
> want is new fault capability.

When conducting an expensive test, one would naturally prefer not to
repeat it on cases that are nearly the same, and therefore unlikely to
expose a bug, at least until all the "more distinctive" cases have
been hit.  Which cases actually do contain a bug is of course
not knowable a priori, and "distinctiveness" is subjective.

The claim of this patch is that uniqueness of call stack is 
a better proxy for likelihood to contain a bug than mere number
of calls to should_fail() -- which can be thought of as the null proxy.

> Fault injection is designed be extensible. It's not only for failslab,
> fail_page_alloc, and fail_make_request.

Sure.

> Common debugfs entries for fault capabilities will be complicated
> soon by pushing new entries for every fault case or pattern.

True.  "space" seems useful only for storage allocation calls.
Should it be dropped from the common set of debugfs entries?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/