On Fri, May 18, 2018 at 09:02:45AM -0700, Christoph Hellwig wrote:
> On Fri, May 18, 2018 at 03:49:18AM -0400, Kent Overstreet wrote:
> > Signed-off-by: Kent Overstreet <kent.overstr...@gmail.com>
>
> Completely lacks any explanation or argument why it would be useful.
It's in the cover letter...
* Dynamic fault injection
I've actually had this code sitting in my tree since forever... I know we have
an existing fault injection framework, but I think this one is quite a bit
nicer
to actually use.
It works very much like the dynamic debug infrastructure - for those who aren't
familiar, dynamic debug makes it so you can list and individually
enable/disable
every pr_debug() callsite in debugfs.
So to add a fault injection site with this, you just stick a call to
dynamic_fault("foobar") somewhere in your code - dynamic_fault() returns true
if
you should fail whatever it is you're testing. And then it'll show up in
debugfs, where you can enable/disable faults by file/linenumber, module, name,
etc.
The patch then also adds macros that wrap all the various memory allocation
functions and fail if dynamic_fault("memory") returns true - which means you
can
see in debugfs every place you're allocating memory and fail all of them or
just
individually (I have tests that iterate over all the faults and flip them on
one
by one). I also use it in bcachefs to add fault injection points for uncommon
error paths in the filesystem startup/recovery path, and for various hard to
test slowpaths that only happen if we race in weird ways (race_fault()).
