Ben,

Joerg reported a crash with the irqsoff tracer with PPC32.
Unfortunately, I don't have a ppc32 that I can work with (my kids took
it from me). I posted a test patch on the BZ that was opened for it:

https://bugzilla.kernel.org/show_bug.cgi?id=16573

Anyway, I was also able to reproduce the crash on PPC64. This patch
handles that case.

The following patch is in:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git

    branch: ppc/ftrace


Steven Rostedt (1):
      powerpc64/tracing: Add frame buffer to calls of trace_hardirqs_on/off

----
 arch/powerpc/include/asm/irqflags.h |   40 ++++++++++++++++++++++++++--------
 1 files changed, 30 insertions(+), 10 deletions(-)
---------------------------
commit 5025019505da6731f8be13940bb978617599c935
Author: Steven Rostedt <srostedt@redhat.com>
Date:   Thu Dec 23 21:07:39 2010 -0800

    powerpc64/tracing: Add frame buffer to calls of trace_hardirqs_on/off
    
    When an interrupt occurs in userspace, we can call trace_hardirqs_on/off()
    With one level stack. But if we have irqsoff tracing enabled,
    it checks both CALLER_ADDR0 and CALLER_ADDR1. The second call
    goes two stack frames up. If this is from user space, then there may
    not exist a second stack.
    
    Add a second stack when calling trace_hardirqs_on/off() otherwise
    the following oops might occur:
    
    Oops: Kernel access of bad area, sig: 11 [#1]
    PREEMPT SMP NR_CPUS=2 PA Semi PWRficient
    last sysfs file: /sys/block/sda/size
    Modules linked in: ohci_hcd ehci_hcd usbcore
    NIP: c0000000000e1c00 LR: c0000000000034d4 CTR: 000000011012c440
    REGS: c00000003e2f3af0 TRAP: 0300   Not tainted  (2.6.37-rc6+)
    MSR: 9000000000001032 <ME,IR,DR>  CR: 48044444  XER: 20000000
    DAR: 00000001ffb9db50, DSISR: 0000000040000000
    TASK = c00000003e1a00a0[2088] 'emacs' THREAD: c00000003e2f0000 CPU: 1
    GPR00: 0000000000000001 c00000003e2f3d70 c00000000084e0d0 c0000000008816e8
    GPR04: ...
[ message continues ]

Hrm... this is really gross :-) So we add gratuituous overhead because
the code below is dumb :-) What about making the code less stupid
instead when poking at the stack and detect it's coming from userspace
instead ?

Cheers,


--

[ message continues ]

Note, when CONFIG_IRQSOFF_TRACE is set, there's already a bit of
overhead :-)

Anyway, I'll have to take a look at how the frame pointer is set up. Or
we could also set up all stacks coming into the kernel to have a "dummy"
frame pointer that wont hurt anything if we index into it.

Anyway, I'm off till the new year, so I'll worry about it then ;-)

-- Steve


--

[ message continues ]

Right, might be simpler to just make them loop back onto themselves or
something like that. I can have a look too if I get a chance.

Cheers,
Ben.

--

[ message continues ]