Skip to content

L
linux-davinci
Switch branch/tag
  1. 04 Feb, 2009 1 commit
    • David S. Miller's avatar
      sparc64: Kill bogus TPC/address truncation during 32-bit faults. · 9b026058
      David S. Miller authored 
      This builds upon eeabac73
("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: default avatarDavid S. Miller <davem@davemloft.net>
      9b026058
  3. 03 Feb, 2009 3 commits
    • Stephen Rothwell's avatar
      sparc: fixup for sparseirq changes · 47a4a0e7
      Stephen Rothwell authored 
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      47a4a0e7
    • David S. Miller's avatar
      sparc64: Validate kernel generated fault addresses on sparc64. · eeabac73
      David S. Miller authored 
      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: default avatarDavid S. Miller <davem@davemloft.net>
      eeabac73
    • David S. Miller's avatar
      sparc64: On non-Niagara, need to touch NMI watchdog in NOHZ mode. · 802c64b3
      David S. Miller authored 
      When we're idling in NOHZ mode, timer interrupts are not running.

Evidence of processing timer interrupts is what the NMI watchdog
uses to determine if the CPU is stuck.

On Niagara, we'll yield the cpu.  This will make the cpu, at
worst, hang out in the hypervisor until an interrupt arrives.
This will prevent the NMI watchdog timer from firing.

However on non-Niagara we just loop executing instructions
which will cause the NMI watchdog to keep firing.  It won't
see timer interrupts happening so it will think the cpu is
stuck.

Fix this by touching the NMI watchdog in the cpu idle loop
on non-Niagara machines.
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      802c64b3
  5. 30 Jan, 2009 1 commit
  7. 29 Jan, 2009 2 commits
  9. 26 Jan, 2009 33 commits