All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.