public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Akinobu Mita <akinobu.mita@gmail.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, ak@suse.de, Don Mullis <dwm@meer.net>
Subject: Re: [patch 0/7] fault-injection capabilities (v5)
Date: Sat, 14 Oct 2006 02:46:24 +0900	[thread overview]
Message-ID: <20061013174623.GA29079@localhost> (raw)
In-Reply-To: <20061012142625.520d3d87.akpm@osdl.org>

On Thu, Oct 12, 2006 at 02:26:25PM -0700, Andrew Morton wrote:

> You've presumably run a kernel with these various things enabled.  What
> happens?  Does the kernel run really slowly?  Does userspace collapse in a
> heap?  Does it oops and die?

I don't feel much slowness with STACKTRACE & FRAME_POINTER and
enabling stacktrace filter. But with enabling STACK_UNWIND I feel
big latency on X. (There are two type of implementation of stacktrace
filter in it [1] using STACKTRACE with FRAME_POINTER, and [2] STACK_UNWIND)

I don't know why there is quite difference between simple STACKTRACE and
STACK_UNWIND. I'm about to try to use rb tree rather than linked list in
unwind.

In order to prevent from breaking other userspace programs and to
inject failures into only a specific code or process, process filter and
stacktrace filter are available. Without using them the system would be
almost unusable.

Now I'm stuck on the script in fault-injection.txt with random 700
modules. This script just tries to load/unload for all available kernel
modules. It usually get several oopses or CPU soft lockup now.  It
seems that relatively large number of them involved around driver model
(drivers/base/*). (I hope recent large number of error handle fixes
especially by Jeff Garzik fix them)

> Also, one place where this infrastructure could be of benefit is in device
> drivers: simulate a bad sector on the disk, a pulled cable, a timeout
> reading from a status register, etc.  If that works well and is useful then
> I can see us encouraging driver developers to wire up fault-injection in
> the major drivers.
> 
> Hence it would be useful at some stage to go in and to actually do all this
> for a particular driver.  As an example implementation for others to
> emulate and as a test for the fault-injection infrastructure itself - we
> may discover that new capabilities are needed as this work is done.
> 
> I wouldn't say this is an urgent thing to be doing, but it is a logical
> next step..

Yes. I'm learning from md/faulty and scsi-debug module what they are
doing and how to integrate such kind of features in general form.


  reply	other threads:[~2006-10-13 17:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-12  7:43 [patch 0/7] fault-injection capabilities (v5) Akinobu Mita
2006-10-12 21:26 ` Andrew Morton
2006-10-13 17:46   ` Akinobu Mita [this message]
2006-10-13 19:00     ` Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2006-10-14 10:52 Jan Beulich

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=20061013174623.GA29079@localhost \
    --to=akinobu.mita@gmail.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=dwm@meer.net \
    --cc=linux-kernel@vger.kernel.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