public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Error in save_stack_trace() on x86_64?
@ 2008-05-11 13:09 Vegard Nossum
  2008-05-11 19:44 ` Arjan van de Ven
  0 siblings, 1 reply; 9+ messages in thread
From: Vegard Nossum @ 2008-05-11 13:09 UTC (permalink / raw)
  To: Ingo Molnar, Arjan van de Ven; +Cc: Linux Kernel Mailing List

Hi,

I am having a problem with v2.6.26-rc1 on x86_64. It seems that
save_stack_trace() is not able to follow page fault boundaries, since
all my saved traces look like this:

RIP: 0010:[<ffffffff8039b004>]  [<ffffffff8039b004>] add_uevent_var+0xb4/0x160
    ...
 [<ffffffff80221f97>] kmemcheck_read+0x127/0x1e0
 [<ffffffff80222269>] kmemcheck_access+0x179/0x1d0
 [<ffffffff8022231f>] kmemcheck_fault+0x5f/0x80
 [<ffffffff8061cd1e>] do_page_fault+0x4de/0x8d0
 [<ffffffff8061a7d9>] error_exit+0x0/0x51
 [<ffffffffffffffff>] 0xffffffffffffffff

I have this in my .config:

CONFIG_STACKTRACE_SUPPORT=y
CONFIG_STACKTRACE=y
...
CONFIG_FRAME_POINTER=y
...
CONFIG_DEBUG_INFO=y


On 32-bit, I am able to see the calls leading up to the page fault as
well. Did I miss something here?


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036

^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: Error in save_stack_trace() on x86_64?
@ 2008-05-11 20:46 Vegard Nossum
  0 siblings, 0 replies; 9+ messages in thread
From: Vegard Nossum @ 2008-05-11 20:46 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: Ingo Molnar, Linux Kernel Mailing List

On Sun, May 11, 2008 at 9:58 PM, Arjan van de Ven <arjan@linux.intel.com> wrote:
> Vegard Nossum wrote: in userspace this trace looks correct.
> 
> > No, it is happening from kernel code. As you can see from the original
> > backtrace, the regs->ip (RIP) (regs taken from the very same
> > do_page_fault()) points at add_uevent_var, which is a kernel function.
> > 
> > 
> > >  if it happens in kernel space... I wonder if the separate exception
> stack
> > > thing
> > >  is hurting us with the stacks not being properly connected...
> > >  (but oopses and the like seem to come out just fine so I kinda doubt
> you're
> > > hitting that)
> > > 
> > > 
> > 
> > Thanks for looking into this.
>  
>  do you happen to have something that I maybe can reproduce?
>  (if you have that it would save me a ton of time in reproducing)
>  

Here's a very dirty hack that reproduces it for me. I'm sorry I don't have
the logs to show it, but it works correctly on 32-bit, but not on 64-bit.

I guess you should also make sure that:

CONFIG_DEBUG_INFO=y
CONFIG_FRAME_POINTER=y
CONFIG_STACKTRACE=y

Thanks.


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036


 arch/x86/mm/fault.c |   17 +++++++++++++++++
 init/main.c         |   12 ++++++++++++
 lib/Kconfig.debug   |    1 +
 3 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index fd7e179..559a5f3 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -25,6 +25,7 @@
 #include <linux/kprobes.h>
 #include <linux/uaccess.h>
 #include <linux/kdebug.h>
+#include <linux/stacktrace.h>
 
 #include <asm/system.h>
 #include <asm/desc.h>
@@ -602,6 +603,22 @@ void __kprobes do_page_fault(struct pt_regs *regs, unsigned long error_code)
 	if (notify_page_fault(regs))
 		return;
 
+	dump_stack();
+
+	struct stack_trace trace;
+	unsigned long entries[16];
+	trace.nr_entries = 0;
+	trace.entries = entries;
+	trace.max_entries = 16;
+	trace.skip = 0;
+	printk(KERN_EMERG "saved stack trace:\n");
+	save_stack_trace(&trace);
+	print_stack_trace(&trace, 0);
+	printk(KERN_EMERG "end saved stack trace\n");
+
+	while(1)
+		halt();
+
 	/*
 	 * We fault-in kernel-space virtual memory on-demand. The
 	 * 'reference' page table is init_mm.pgd.
diff --git a/init/main.c b/init/main.c
index ddada7a..d9fb240 100644
--- a/init/main.c
+++ b/init/main.c
@@ -531,6 +531,16 @@ void __init __weak thread_info_cache_init(void)
 {
 }
 
+void noinline trigger_page_fault(void) {
+	struct page *p = alloc_pages(GFP_KERNEL, 0);
+	unsigned long addr = page_address(p);
+	set_memory_4k(addr, 0);
+	int level;
+	pte_t *pte = lookup_address(addr, &level);
+	set_pte(pte, __pte(pte_val(*pte) & ~_PAGE_PRESENT));
+	*(char*) addr = 0;
+}
+
 asmlinkage void __init start_kernel(void)
 {
 	char * command_line;
@@ -680,6 +690,8 @@ asmlinkage void __init start_kernel(void)
 
 	acpi_early_init(); /* before LAPIC and SMP init */
 
+	trigger_page_fault();
+
 	/* Do the rest non-__init'ed, we're now alive */
 	rest_init();
 }
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index d2099f4..3fc1247 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -419,6 +419,7 @@ config DEBUG_LOCKING_API_SELFTESTS
 
 config STACKTRACE
 	bool
+	default y
 	depends on DEBUG_KERNEL
 	depends on STACKTRACE_SUPPORT
 
-- 
1.5.4.1


^ permalink raw reply related	[flat|nested] 9+ messages in thread
end of thread, other threads:[~2008-05-18 20:23 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-05-11 13:09 Error in save_stack_trace() on x86_64? Vegard Nossum
2008-05-11 19:44 ` Arjan van de Ven
2008-05-11 19:56   ` Vegard Nossum
2008-05-11 19:58     ` Arjan van de Ven
2008-05-18 17:13   ` Vegard Nossum
2008-05-18 18:31     ` Vegard Nossum
2008-05-18 18:52       ` Arjan van de Ven
2008-05-18 20:23         ` Vegard Nossum
  -- strict thread matches above, loose matches on Subject: below --
2008-05-11 20:46 Vegard Nossum

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox