linux-toradex.git/arch/parisc/kernel/traps.c, branch v3.9.2

taint: add explicit flag to show whether lock dep is still OK.

2013-01-21T06:47:57+00:00

Fix up all callers as they were before, with make one change: an
unsigned module taints the kernel, but doesn't turn off lockdep.

Signed-off-by: Rusty Russell

Disintegrate asm/system.h for PA-RISC

2012-03-28T17:30:02+00:00

Disintegrate asm/system.h for PA-RISC.

Signed-off-by: David Howells 
cc: linux-parisc@vger.kernel.org

atomic: use

2011-07-26T23:49:47+00:00

This allows us to move duplicated code in 
(atomic_inc_not_zero() for now) to 

Signed-off-by: Arun Sharma 
Reviewed-by: Eric Dumazet 
Cc: Ingo Molnar 
Cc: David Miller 
Cc: Eric Dumazet 
Acked-by: Mike Frysinger 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

parisc: fix warning in traps.c

2009-08-29T05:37:20+00:00

On Tue, Aug 18, 2009 at 01:45:17PM -0400, John David Anglin wrote:
>  CC      arch/parisc/kernel/traps.o
> arch/parisc/kernel/traps.c: In function 'handle_interruption':
> arch/parisc/kernel/traps.c:535:18: warning: operation on 'regs->iasq[0]'
> may be undefined

Yes - Line 535 should use both [0] and [1].

Reported-by: John David Anglin 
Signed-off-by: Grant Grundler 
Signed-off-by: Kyle McMartin 
Signed-off-by: Linus Torvalds

Remove multiple KERN_ prefixes from printk formats

2009-07-08T17:30:03+00:00

Commit 5fd29d6ccbc98884569d6f3105aeca70858b3e0f ("printk: clean up
handling of log-levels and newlines") changed printk semantics.  printk
lines with multiple KERN_ prefixes are no longer emitted as
before the patch.

 is now included in the output on each additional use.

Remove all uses of multiple KERN_s in formats.

Signed-off-by: Joe Perches 
Signed-off-by: Linus Torvalds

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

2009-03-31T02:51:35+00:00

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:34+00:00

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:27+00:00

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:46+00:00

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:39+00:00

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