public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Akinobu Mita <akinobu.mita@gmail.com>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org,
	Don Mullis <dwm@meer.net>,
	Valdis.Kletnieks@vt.edu, jbeulich@novell.com
Subject: Re: [patch 8/8] stacktrace filtering for fault-injection capabilities
Date: Mon, 16 Oct 2006 11:31:39 +0200	[thread overview]
Message-ID: <200610161131.39210.ak@suse.de> (raw)
In-Reply-To: <20061010115255.902380817@gmail.com>


> Index: work-fault-inject/lib/Kconfig.debug
> ===================================================================
> --- work-fault-inject.orig/lib/Kconfig.debug
> +++ work-fault-inject/lib/Kconfig.debug
> @@ -401,6 +401,8 @@ config LKDTM
>  
>  config FAULT_INJECTION
>  	bool
> +	select STACKTRACE
> +	select FRAME_POINTER

I'm afraid this won't work fully reliably on i386/x86-64 at least. The problem 
is that if even with frame pointers the new unwinder will try its unwinding
first and if it gets stuck it will log the fallback entries into the stack
trace buffer too. And those fallback entries can be randomly everything left over
from previous stack traces. Then the fault injection will be more
like Russian roulette and could randomly hit other code paths too.

To make this work there would need to be some way to turn off fallback
for these particular stack traces. 

Or maybe just always use frame pointer
there, but even that will likely not help because the few places
where the dwarf2 unwinder still gets stuck (usually assembly code) 
are usually broken with frame pointers too.

-Andi


       reply	other threads:[~2006-10-16  9:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20061010115219.176309702@gmail.com>
     [not found] ` <20061010115255.902380817@gmail.com>
2006-10-16  9:31   ` Andi Kleen [this message]
2006-09-14 10:20 [patch 0/8] fault-injection capabilities (v3) Akinobu Mita
2006-09-14 10:20 ` [patch 8/8] stacktrace filtering for fault-injection capabilities Akinobu Mita
2006-09-19  5:56   ` Don Mullis
2006-09-19  9:08     ` Akinobu Mita
2006-09-19  5:57   ` Don Mullis
2006-09-19  9:09     ` Akinobu Mita
2006-09-19 17:35       ` Don Mullis
2006-09-20 13:39         ` Akinobu Mita
2006-09-20 20:02           ` Don Mullis

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=200610161131.39210.ak@suse.de \
    --to=ak@suse.de \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=akinobu.mita@gmail.com \
    --cc=akpm@osdl.org \
    --cc=dwm@meer.net \
    --cc=jbeulich@novell.com \
    --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