kernel.git/arch/parisc/kernel/traps.c, branch linux-2.6.30.y

parisc: oops_enter()/oops_exit() in die()

2009-03-31T02:51:35Z

As pointed out by Russell in http://marc.info/?l=linux-arch&m=118208089204630&w=2 Signed-off-by: Helge Deller Signed-off-by: Kyle McMartin

parisc: add ftrace (function and graph tracer) functionality

2009-03-31T02:51:34Z

This patch adds the ftrace debugging functionality to the parisc kernel. It will currently only work with 64bit kernels, because the gcc options -pg and -ffunction-sections can't be enabled at the same time and -ffunction-sections is still needed to be able to link 32bit kernels. Signed-off-by: Helge Deller Signed-off-by: Kyle McMartin

parisc: export length of os_hpmc vector

2009-01-05T19:18:27Z

and use this instead of dealing with exporting start/end and toying with function descriptors. Signed-off-by: Kyle McMartin

parisc: fix kernel crash (protection id trap) when compiling ruby1.9

2009-01-05T19:16:46Z

On Wed, Dec 17, 2008 at 11:46:05PM +0100, Helge Deller wrote: > Honestly, I can't decide whether to apply this. It really should never happen in the kernel, since the kernel can guarantee it won't get the access rights failure (highest privilege level, and can set %sr and %protid to whatever it wants.) It really genuinely is a bug that probably should panic the kernel. The only precedent I can easily see is x86 fixing up a bad iret with a general protection fault, which is more or less analogous to code 27 here. On the other hand, taking the exception on a userspace access really isn't all that critical, and there's fundamentally little reason for the kernel not to SIGSEGV the process, and continue... Argh. (btw, I've instrumented my do_sys_poll with a pile of assertions that %cr8 << 1 == %sr3 == current->mm.context... let's see if where we're getting corrupted is deterministic, though, I would guess that it won't be.) Signed-off-by: Kyle McMartin

parisc: fix kernel crash when unwinding a userspace process

2008-11-26T22:22:39Z

Any user on existing parisc 32- and 64bit-kernels can easily crash the kernel and as such enforce a DSO. A simple testcase is available here: http://gsyprf10.external.hp.com/~deller/crash.tgz The problem is introduced by the fact, that the handle_interruption() crash handler calls the show_regs() function, which in turn tries to unwind the stack by calling parisc_show_stack(). Since the stack contains userspace addresses, a try to unwind the stack is dangerous and useless and leads to the crash. The fix is trivial: For userspace processes a) avoid to unwind the stack, and b) avoid to resolve userspace addresses to kernel symbol names. While touching this code, I converted print_symbol() to %pS printk formats and made parisc_show_stack() static. An initial patch for this was written by Kyle McMartin back in August: http://marc.info/?l=linux-parisc&m=121805168830283&w=2 Compile and run-tested with a 64bit parisc kernel. Signed-off-by: Helge Deller Cc: Grant Grundler Cc: Matthew Wilcox Cc: [2.6.25.x, 2.6.26.x, 2.6.27.x, earlier...] Signed-off-by: Andrew Morton Signed-off-by: Kyle McMartin

parisc: replace remaining FUNCTION occurrences

2008-05-15T14:38:54Z

__FUNCTION__ is gcc-specific, use __func__ Signed-off-by: Harvey Harrison Cc: Kyle McMartin Cc: Matthew Wilcox Cc: Grant Grundler Signed-off-by: Andrew Morton Signed-off-by: Kyle McMartin

[PARISC] clean up show_stack

2008-03-16T02:12:15Z

When we show_regs, we obviously have a struct pt_regs of the calling frame. Use these in show_stack so we don't have the entire bogus call trace up to the show_stack call. Signed-off-by: Kyle McMartin

[PARISC] dump_stack in show_regs

2008-03-16T02:12:01Z

Originally, show_stack was used in BUG() output. However, a recent commit changed it to print register state (no idea what that's supposed to help, really...) and parisc was missing a backtrace because of it. Signed-off-by: Kyle McMartin

Use helpers to obtain task pid in printks (arch code)

2007-10-19T18:53:43Z

One of the easiest things to isolate is the pid printed in kernel log. There was a patch, that made this for arch-independent code, this one makes so for arch/xxx files. It took some time to cross-compile it, but hopefully these are all the printks in arch code. Signed-off-by: Alexey Dobriyan Signed-off-by: Pavel Emelyanov Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Report that kernel is tainted if there was an OOPS

2007-07-17T17:23:02Z

If the kernel OOPSed or BUGed then it probably should be considered as tainted. Thus, all subsequent OOPSes and SysRq dumps will report the tainted kernel. This saves a lot of time explaining oddities in the calltraces. Signed-off-by: Pavel Emelianov Acked-by: Randy Dunlap Cc: Signed-off-by: Andrew Morton [ Added parisc patch from Matthew Wilson -Linus ] Signed-off-by: Linus Torvalds