All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Akinobu Mita <mita@miraclelinux.com>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org, okuji@enbug.org
Subject: Re: [patch 3/6] fault-injection capability for alloc_pages()
Date: Thu, 31 Aug 2006 12:25:02 +0200	[thread overview]
Message-ID: <200608311225.02101.ak@suse.de> (raw)
In-Reply-To: <20060831100820.697247381@localhost.localdomain>

On Thursday 31 August 2006 12:07, Akinobu Mita wrote:
> This patch provides fault-injection capability for alloc_pages()
> 
> boot option:
> 
> 	fail_page_alloc=<probability>,<interval>,<times>,<space>
> 
> 	<probability>
> 
> 		specifies how often it should fail in percent.
> 
> 	<interval>
> 
> 		specifies the interval of failures.
> 
> 	<times>
> 
> 		specifies how many times failures may happen at most.
> 
> 	<space>
> 
> 		specifies the size of free space where memory can be allocated
> 		safely in pages.
> 
> Example:
> 
> 	fail_page_alloc=100,10,-1,0
> 
> page allocation fails once per 10 times.

I still think this will need some better filters to be useful. At least
a optional uid filter perhaps (make sure to handle the interrupt case
correctly, interrupts don't belong to the uid) , and perhaps an option to only 
fail GFP_ATOMIC.

With arbitary failing the system will just be unusable, right? Or would
you run some system you use this way? @)

Another possibility would be to look up __builtin_return_address(0) in 
the module table and allow failing only for a specific module.


-andi

  reply	other threads:[~2006-08-31 10:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-31 10:07 [patch 0/6] RFC: fault-injection capabilities (v2) Akinobu Mita
2006-08-31 10:07 ` [patch 1/6] fault-injection capabilities infrastructure Akinobu Mita
2006-08-31 10:22   ` Andi Kleen
2006-08-31 10:07 ` [patch 2/6] fault-injection capability for kmalloc Akinobu Mita
2006-08-31 10:07 ` [patch 3/6] fault-injection capability for alloc_pages() Akinobu Mita
2006-08-31 10:25   ` Andi Kleen [this message]
2006-08-31 10:35     ` Akinobu Mita
2006-08-31 10:45       ` Andi Kleen
2006-08-31 10:08 ` [patch 4/6] fault-injection capability for disk IO Akinobu Mita
2006-08-31 10:08 ` [patch 5/6] debugfs entries for configuration Akinobu Mita
2006-08-31 10:08 ` [patch 6/6] process filtering for fault-injection capabilities Akinobu Mita
2006-08-31 17:29 ` [patch 0/6] RFC: fault-injection capabilities (v2) Josh Triplett
2006-08-31 18:31   ` Kyle Moffett

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=200608311225.02101.ak@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 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.