public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Akinobu Mita <mita@miraclelinux.com>
Cc: akpm@osdl.org, okuji@enbug.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 0/5] RFC: fault-injection capabilities
Date: 23 Aug 2006 14:06:06 +0200	[thread overview]
Message-ID: <p73pser64i9.fsf@verdi.suse.de> (raw)
In-Reply-To: <20060823113243.210352005@localhost.localdomain>

Akinobu Mita <mita@miraclelinux.com> writes:

> This patch set provides some fault-injection capabilities.
> 
> - kmalloc failures
> 
> - alloc_pages() failures
> 
> - disk IO errors
> 
> We can see what really happens if those failures happen.

Nice.

The SUSE kernel has a crasher module that is also quite useful for testing.
What it does basically is to always allocate/free memory and overwrite
the memory and check if the memory hasn't been changed by someone else.
Perhaps something like that could be incorporated into your framework too?

I put a copy of the suse patch in 
http://www.firstfloor.org/~andi/crasher-26.diff


> 
> In order to enable these fault-injection capabilities:

However I'm not sure they're too useful right now.  The problem is
that they're too global and might render the system unusable. Have you
considered adding some more filters, like uid/gid to fail only (
I think that would be useful because then it would be possible
to run test suites with faults while keeping other parts of the system
functional) or maybe even a list of callers to test? e.g. only
failing for module foo would be nice.

-Andi


  parent reply	other threads:[~2006-08-23 12:06 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-23 11:32 [patch 0/5] RFC: fault-injection capabilities Akinobu Mita
2006-08-23 11:32 ` [patch 1/5] fail-injection library Akinobu Mita
2006-08-23 12:09   ` Andi Kleen
2006-08-23 11:32 ` [patch 2/5] fail-injection capability for kmalloc Akinobu Mita
2006-08-23 11:32 ` [patch 3/5] fail-injection capability for alloc_pages() Akinobu Mita
2006-08-23 11:32 ` [patch 4/5] fail-injection capability for disk IO Akinobu Mita
2006-08-23 12:03   ` Jens Axboe
2006-08-23 17:27     ` Andrew Morton
2006-08-23 18:01       ` Jens Axboe
2006-08-23 18:16         ` Ric Wheeler
2006-08-23 18:26           ` Jens Axboe
2006-08-23 18:22       ` Hans Reiser
2006-08-23 12:07   ` Andi Kleen
2006-08-23 12:10     ` Jens Axboe
2006-08-23 19:34       ` Mario 'BitKoenig' Holbe
2006-08-23 19:42         ` Ric Wheeler
2006-08-23 11:32 ` [patch 5/5] debugfs entries for configuration Akinobu Mita
2006-08-23 12:06 ` Andi Kleen [this message]
2006-08-23 14:18 ` [patch 0/5] RFC: fault-injection capabilities Alexey Dobriyan
2006-08-24 18:41 ` Valdis.Kletnieks

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=p73pser64i9.fsf@verdi.suse.de \
    --to=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mita@miraclelinux.com \
    --cc=okuji@enbug.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox