Re: ARM + jprobes/kretprobes SEGV/hangs/OOPS in 2.6.29 kernel

[venki kaps <venkiece2005@gmail.com>]

I have done some more analysis with respect to ARM kretprobes
and describing as below,

Before disabling unwinding support,
i have tested mainlined sample kretprobes_example.c with some changes.
the changes are,

Index: b/samples/kprobes/kretprobe_example.c
===================================================================
--- a/samples/kprobes/kretprobe_example.c
+++ b/samples/kprobes/kretprobe_example.c
@@ -59,6 +59,9 @@ static int ret_handler(struct kretprobe_
        s64 delta;
        ktime_t now;

+       printk("%s %d, Stack_dump :\n", __FILE__, __LINE__);
+       dump_stack();
+
        now = ktime_get();
        delta = ktime_to_ns(ktime_sub(now, data->entry_stamp));
        printk(KERN_INFO "%s returned %d and took %lld ns to execute\n",

$ insmod kretprobe_example.ko
$ ls
    <---- system hang

As i mentioned jprobes and kretprobes are having some issues with backtrace
with enabling unwinding support and as we know well about ARM, unwinding tables
are not stabilized which was pending issue in present kernels.

After disabling unwinding support,
              Kernel hacking  --->
	                 -*- frame pointer support
	            [] Enable stack unwinding support

Based on the above settings, I have verified the above test with dump_stack and
noticed test result as PASS.

I wanted to rely on FRAME_POINTER So have just added
'''select FRAME_POINTER''' to kprobe related configs as below as,

Index: b/samples/Kconfig
===================================================================
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@ -31,6 +31,7 @@ config SAMPLE_KOBJECT
 config SAMPLE_KPROBES
 	tristate "Build kprobes examples -- loadable modules only"
 	depends on KPROBES && m
+	select FRAME_POINTER
 	help
 	  This build several kprobes example modules.

@@ -38,6 +39,7 @@ config SAMPLE_KRETPROBES
 	tristate "Build kretprobes example -- loadable modules only"
 	default m
 	depends on SAMPLE_KPROBES && KRETPROBES
+	select FRAME_POINTER

 config SAMPLE_PSRWLOCK
 	tristate "Build psrwlock example -- loadable modules only"
Index: b/arch/Kconfig
===================================================================
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -36,6 +36,7 @@ config KPROBES
 	bool "Kprobes"
 	depends on KALLSYMS && MODULES
 	depends on HAVE_KPROBES
+	select FRAME_POINTER
 	help
 	  Kprobes allows you to trap at almost any kernel address and
 	  execute a callback function.  register_kprobe() establishes
@@ -68,6 +69,7 @@ config HAVE_SYSCALL_WRAPPERS
 config KRETPROBES
 	def_bool y
 	depends on KPROBES && HAVE_KRETPROBES
+	select FRAME_POINTER

 config HAVE_IOREMAP_PROT
 	bool

I have some queries,
- shall i rely on FRAME_POINTER in kprobe related configs?
- shall i proceed with above changes?

Best Regards,
Venkappa



On Tue, Sep 1, 2009 at 11:26 PM, Nicolas Pitre <nico@cam.org> wrote:
> On Tue, 1 Sep 2009, Catalin Marinas wrote:
>
>> On Tue, 2009-09-01 at 15:25 +0100, Russell King wrote:
>> > On Tue, Sep 01, 2009 at 02:54:54PM +0100, Catalin Marinas wrote:
>> > > venki kaps <venkiece2005@gmail.com> wrote:
>> > > > I have found the exact problem with respect to ARM jprobes.
>> > > >
>> > > > The problem with configure i.e, CONFIG_ARM_UNWIND = y; is enabled.
>> > >
>> > > I haven't followed the kprobes implementation for ARM but does it make
>> > > any assumptions about the existence of a frame pointer on the stack?
>> > > Enabling stack unwinding automatically disables the framepointer.
>> >
>> > If it uses CALLER_ADDRESSx() then it won't work with unwinding enabled.
>> > See 5613/1 (which is pending in the devel branch.)
>>
>> In addition to that, when CONFIG_FRAME_POINTER is disabled, the lr
>> register isn't always saved on the stack by the called function. I'm not
>> sure whether kretprobe_trampoline is aware of this.
>
> The way a kretprobe works is to put a trap at the very first instruction
> of the targetted function, preserve the value of LR when the trap is
> hit, and substitute it with the address of kretprobe_trampoline.  Then
> the original first instruction is emulated to pass over the trap point
> and normal execution is resumed.  So whether or not LR is then saved on
> the stack doesn't matter to kretprobe_trampoline as it will restore the
> LR value saved during the initial trap.
>
> Of course if you end up generating a backtrace within a kretprobed
> function then the result might look funny.
>
>
> Nicolas
>