Commit graph

9 commits

Author SHA1 Message Date
David S. Miller
4b17764737 sparc: Support show_unhandled_signals.
Just faults right now, will add other traps later.

Signed-off-by: David S. Miller <davem@davemloft.net>
2010-03-01 00:02:23 -08:00
David S. Miller
a084b6678a sparc: Add missing SW perf fault events.
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-01-20 16:23:03 -08:00
David S. Miller
4ed5d5e429 sparc64: Add some missing __kprobes annotations to kernel fault paths.
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-12-10 18:08:29 -08:00
David S. Miller
135d082171 sparc64: Use kprobes_built_in() to avoid ifdefs in fault_64.c
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-12-10 18:02:19 -08:00
David S. Miller
a923c28fc5 sparc: Use page_fault_out_of_memory() for VM_FAULT_OOM.
As noted by Nick Piggin.

Signed-off-by: David S. Miller <davem@davemloft.net>
2009-08-02 19:17:15 -07:00
Linus Torvalds
d06063cc22 Move FAULT_FLAG_xyz into handle_mm_fault() callers
This allows the callers to now pass down the full set of FAULT_FLAG_xyz
flags to handle_mm_fault().  All callers have been (mechanically)
converted to the new calling convention, there's almost certainly room
for architectures to clean up their code and then add FAULT_FLAG_RETRY
when that support is added.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-21 13:08:22 -07:00
David S. Miller
9b02605826 sparc64: Kill bogus TPC/address truncation during 32-bit faults.
This builds upon eeabac7386
("sparc64: Validate kernel generated fault addresses on sparc64.")

Upon further consideration, we actually should never see any
fault addresses for 32-bit tasks with the upper 32-bits set.

If it does every happen, by definition it's a bug.  Whatever
context created that fault would only have that fault satisfied
if we used the full 64-bit address.  If we truncate it, we'll
always fault the wrong address and we'll always loop faulting
forever.

So catch such conditions and mark them as errors always.  Log
the error and fail the fault.

Signed-off-by: David S. Miller <davem@davemloft.net>
2009-02-03 16:28:23 -08:00
David S. Miller
eeabac7386 sparc64: Validate kernel generated fault addresses on sparc64.
In order to handle all of the cases of address calculation overflow
properly, we run sparc 32-bit processes in "address masking" mode
when running on a 64-bit kernel.

Address masking mode zeros out the top 32-bits of the address
calculated for every load and store instruction.

However, when we're in privileged mode we have to run with that
address masking mode disabled even when accessing userspace from
the kernel.

To "simulate" the address masking mode we clear the top-bits by
hand for 32-bit processes in the fault handler.

It is the responsibility of code in the compat layer to properly
zero extend addresses used to access userspace.  If this isn't
followed properly we can get into a fault loop.

Say that the user address is 0xf0000000 but for whatever reason
the kernel code sign extends this to 64-bit, and then the kernel
tries to access the result.

In such a case we'll fault on address 0xfffffffff0000000 but the fault
handler will process that fault as if it were to address 0xf0000000.
We'll loop faulting forever because the fault never gets satisfied.

So add a check specifically for this case, when the kernel is faulting
on a user address access and the addresses don't match up.

This code path is sufficiently slow path, and this bug is sufficiently
painful to diagnose, that this kind of bug check is warranted.

Signed-off-by: David S. Miller <davem@davemloft.net>
2009-02-02 22:08:15 -08:00
Sam Ravnborg
27137e5285 sparc,sparc64: unify mm/
- move all sparc64/mm/ files to arch/sparc/mm/
- commonly named files are named _64.c
- add files to sparc/mm/Makefile preserving link order
- delete now unused sparc64/mm/Makefile
- sparc64 now finds mm/ in sparc

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-12-04 09:16:59 -08:00
Renamed from arch/sparc64/mm/fault.c (Browse further)