Timo Juhani Lindfors <timo.lindf...@iki.fi> writes:
> thanks for the pointer. I forked gen_code_all.sh to a version that
> incrementally adds new probes to the set until the kernel crashes.
This process revealed only 17 problematic functions:
xen_set_debugreg
xen_get_debugreg
xen_irq_enable_direct_reloc
xen_irq_disable_direct
xen_irq_disable_direct_end
xen_save_fl_direct
xen_restore_fl_direct_reloc
check_events
xen_adjust_exception_frame
xen_iret
xen_iret_reloc
xen_sysret64
xen_sysret64_reloc
test_ti_thread_flag.clone.16
hash_ptr.clone.12
inat_get_opcode_attribute
system_call_after_swapgs
I blacklisted these and I can now load the huge module generated by
gen_code_all.sh succesfully:
$ lsmod | grep kprobe_module
kprobe_module 3432584 -Timo
I then blacklisted these in dwflpp.cxx with the attached patch and
voila, the original bug does not occur anymore :-)
lindi2:~/tmp$ cat > mmap-trace.stp <<EOF
> global trace
>
> function trace(entry_p) {
> if(tid() in trace)
> printf("%s%s%s\n",
> thread_indent(entry_p),
> (entry_p>0?"->":"<-"),
> probefunc())
> }
>
> probe syscall.execve {
> # printf("%s\n", filename);
> if (filename != "./mmap") next
> trace[tid()] = 1
> trace(1)
> }
> #probe syscall.execve.return {
> # trace(-1)
> # delete trace[tid()]
> #}
> #probe kernel.function("*@mm/*.c").call { trace(1) }
> #probe kernel.function("*@mm/*.c").return { trace(-1) }
>
> probe kernel.function("*@*/*.c").call { trace(1) }
> probe kernel.function("*@*/*.c").return { trace(-1) }
>
> probe begin {
> printf("begin\n");
> }
> EOF
lindi2:~/tmp$ sudo stap ./mmap-trace.stp
begin
How should we continue from here? If systemtap upstream accepts this
should somebody then try to get the missing __kprobe annotations also to
Linux?
-Timo
>From 056a908d27dd7ab0949a33df61e57ca371061604 Mon Sep 17 00:00:00 2001
From: Timo Juhani Lindfors <timo.lindf...@iki.fi>
Date: Thu, 18 Aug 2011 20:14:11 +0300
Subject: [PATCH] Add few more entries to kprobe blacklist
Each one of these is able to crash the Debian kernel
linux-image-3.0.0-1-amd64 3.0.0-1
when it is run as a xen domU. See Debian bug #604453.
---
dwflpp.cxx | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/dwflpp.cxx b/dwflpp.cxx
index 790caf4..63e4fd4 100644
--- a/dwflpp.cxx
+++ b/dwflpp.cxx
@@ -3001,6 +3001,23 @@ dwflpp::build_blacklist()
blfn += "|sync_regs";
blfn += "|unhandled_fault";
blfn += "|unknown_nmi_error";
+ blfn += "|xen_set_debugreg";
+ blfn += "|xen_get_debugreg";
+ blfn += "|xen_irq_enable_direct_reloc";
+ blfn += "|xen_irq_disable_direct";
+ blfn += "|xen_irq_disable_direct_end";
+ blfn += "|xen_save_fl_direct";
+ blfn += "|xen_restore_fl_direct_reloc";
+ blfn += "|check_events";
+ blfn += "|xen_adjust_exception_frame";
+ blfn += "|xen_iret";
+ blfn += "|xen_iret_reloc";
+ blfn += "|xen_sysret64";
+ blfn += "|xen_sysret64_reloc";
+ blfn += "|test_ti_thread_flag.clone.16";
+ blfn += "|hash_ptr.clone.12";
+ blfn += "|inat_get_opcode_attribute";
+ blfn += "|system_call_after_swapgs";
// Lots of locks
blfn += "|.*raw_.*_lock.*";
--
1.7.2.5
