From: Scott Porter <scott@opengridcomputing.com>
To: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Fault Injection issues: stacktrace x86_64 and failslab NUMA
Date: Fri, 20 Apr 2007 13:55:54 -0500 [thread overview]
Message-ID: <1177095354.25165.48.camel@scott-desktop.site> (raw)
I'm attempting to use Fault Injection stacktrace filtering on an x86_64
platform (see config details below) and finding problems:
(1) Apparently stacktrace on x86_64 isn't always reliable but the fault
injection code path to save a stack trace looks *completely* unreliable
(2) CONFIG_NUMA and failslab don't mix -- the NUMA code successfully
allocates after the fault injection code thinks it has failed!
Details:
(1) When the fault injection code is saving a stack trace to compare
require-start/require-end addresses, it employs the following code in
arch/x86_64/kernel/traps.c where the task is the currently running
thread:
if (!stack) {
unsigned long dummy;
stack = &dummy;
if (tsk && tsk != current)
stack = (unsigned long *)tsk->thread.rsp;
}
Can anyone explain how this code could possibly get a valid stack
pointer using "&dummy" on an automatic variable defined in the middle of
a routine that has arguments and other auto variables? When I look at
the stack buffer that is saved it contains only entries for
"should_fail()" and so fail_stacktrace() NEVER matches on the start/end
addresses.
Prior to this patch:
2006-09-26 Andi Kleen [PATCH] Merge stacktrace and show_trace
the save_stack_trace() routine would get the current thread stack
pointer this way:
- if (!task || task == current) {
- /* Grab rbp right from our regs: */
- asm ("mov %%rbp, %0" : "=r" (stack));
Any pointers you can give to help me understand x86_64 stack frames
and/or how this code should work is appreciated!
I'd like to take advantage of the Fault Injection capabilities to debug
error paths in a driver but without reliable stacktrace it looks like
I'm left to invent my own kmalloc() error injection methods. Anybody
know how to interpose (a la LD_PRELOAD) on exported kernel interfaces
like kmalloc() for a loadable kernel module?! I'm thinking that Fault
Injection for failslab and fail-page-alloc provided as a separate
loadable module would be more appealing than having to add debug code
into the kernel anyways?
(2) The fault injection code in mm/slab.c within ____cache_alloc()
returns NULL when should_failslab() returns true. HOWEVER, later code
in __cache_alloc() compiled in with NUMA_BUILD (via CONFIG_NUMA)
successfully allocates memory from another node and prevents the error
injection from really failing:
if (!objp)
objp = ____cache_alloc(cachep, flags);
/*
* We may just have run out of memory on the local node.
* ____cache_alloc_node() knows how to locate memory on other nodes
*/
if (NUMA_BUILD && !objp)
objp = ____cache_alloc_node(cachep, flags, numa_node_id());
Not sure what the best way is to deal with this (other than turning off
CONFIG_NUMA!).
Config details:
2.6.20.1 x86_64
CONFIG_DEBUG_KERNEL=y
CONFIG_STACKTRACE=y
CONFIG_FRAME_POINTER=y
CONFIG_FAULT_INJECTION=y
CONFIG_FAILSLAB=y
CONFIG_FAIL_PAGE_ALLOC=y
# CONFIG_FAIL_MAKE_REQUEST is not set
CONFIG_FAULT_INJECTION_DEBUG_FS=y
CONFIG_NUMA=y
next reply other threads:[~2007-04-20 19:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-20 18:55 Scott Porter [this message]
2007-04-21 21:52 ` Scott Porter
2007-04-21 22:10 ` Andi Kleen
2007-04-22 7:06 ` Akinobu Mita
2007-04-22 9:09 ` [PATCH] fault injection: disable stacktrace filter for x86-64 Akinobu Mita
2007-04-22 9:11 ` [PATCH] fault injection: fix failslab with CONFIG_NUMA Akinobu Mita
2007-04-22 9:12 ` [PATCH] fault injection: add entry to MAINTAINERS Akinobu Mita
2007-04-23 5:05 ` [PATCH] fault injection: fix failslab with CONFIG_NUMA Pekka J Enberg
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=1177095354.25165.48.camel@scott-desktop.site \
--to=scott@opengridcomputing.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
all inboxes | Powered by JetHome®