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

parisc: fix interruption handler to respect pagefault_disable()

2013-10-22T08:02:25+00:00

commit 59b33f148cc08fb33cbe823fca1e34f7f023765e upstream.

Running an "echo t > /proc/sysrq-trigger" crashes the parisc kernel.  The
problem is, that in print_worker_info() we try to read the workqueue info via
the probe_kernel_read() functions which use pagefault_disable() to avoid
crashes like this:
    probe_kernel_read(&pwq, &worker->current_pwq, sizeof(pwq));
    probe_kernel_read(&wq, &pwq->wq, sizeof(wq));
    probe_kernel_read(name, wq->name, sizeof(name) - 1);

The problem here is, that the first probe_kernel_read(&pwq) might return zero
in pwq and as such the following probe_kernel_reads() try to access contents of
the page zero which is read protected and generate a kernel segfault.

With this patch we fix the interruption handler to call parisc_terminate()
directly only if pagefault_disable() was not called (in which case
preempt_count()==0).  Otherwise we hand over to the pagefault handler which
will try to look up the faulting address in the fixup tables.

Signed-off-by: Helge Deller 
Signed-off-by: John David Anglin  
Signed-off-by: Helge Deller 
Signed-off-by: Greg Kroah-Hartman

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