1. 03 Feb, 2009 3 commits
    • Stephen Rothwell's avatar
      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
  2. 30 Jan, 2009 1 commit
  3. 29 Jan, 2009 2 commits
  4. 26 Jan, 2009 34 commits