1. 25 10月, 2014 3 次提交
    • C
      arm64: Fix memblock current_limit with 64K pages and 48-bit VA · 3dec0fe4
      Catalin Marinas 提交于
      With 48-bit VA space, the 64K page configuration uses 3 levels instead
      of 2 and PUD_SIZE != PMD_SIZE. Since with 64K pages we only cover
      PMD_SIZE with the initial swapper_pg_dir populated in head.S, the
      memblock current_limit needs to be set accordingly in map_mem() to avoid
      allocating unmapped memory. The memblock current_limit is progressively
      increased as more blocks are mapped.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      3dec0fe4
    • D
      sparc64: Implement __get_user_pages_fast(). · 06090e8e
      David S. Miller 提交于
      It is not sufficient to only implement get_user_pages_fast(), you
      must also implement the atomic version __get_user_pages_fast()
      otherwise you end up using the weak symbol fallback implementation
      which simply returns zero.
      
      This is dangerous, because it causes the futex code to loop forever
      if transparent hugepages are supported (see get_futex_key()).
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      06090e8e
    • D
      sparc64: Fix register corruption in top-most kernel stack frame during boot. · ef3e035c
      David S. Miller 提交于
      Meelis Roos reported that kernels built with gcc-4.9 do not boot, we
      eventually narrowed this down to only impacting machines using
      UltraSPARC-III and derivitive cpus.
      
      The crash happens right when the first user process is spawned:
      
      [   54.451346] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
      [   54.451346]
      [   54.571516] CPU: 1 PID: 1 Comm: init Not tainted 3.16.0-rc2-00211-gd7933ab7 #96
      [   54.666431] Call Trace:
      [   54.698453]  [0000000000762f8c] panic+0xb0/0x224
      [   54.759071]  [000000000045cf68] do_exit+0x948/0x960
      [   54.823123]  [000000000042cbc0] fault_in_user_windows+0xe0/0x100
      [   54.902036]  [0000000000404ad0] __handle_user_windows+0x0/0x10
      [   54.978662] Press Stop-A (L1-A) to return to the boot prom
      [   55.050713] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
      
      Further investigation showed that compiling only per_cpu_patch() with
      an older compiler fixes the boot.
      
      Detailed analysis showed that the function is not being miscompiled by
      gcc-4.9, but it is using a different register allocation ordering.
      
      With the gcc-4.9 compiled function, something during the code patching
      causes some of the %i* input registers to get corrupted.  Perhaps
      we have a TLB miss path into the firmware that is deep enough to
      cause a register window spill and subsequent restore when we get
      back from the TLB miss trap.
      
      Let's plug this up by doing two things:
      
      1) Stop using the firmware stack for client interface calls into
         the firmware.  Just use the kernel's stack.
      
      2) As soon as we can, call into a new function "start_early_boot()"
         to put a one-register-window buffer between the firmware's
         deepest stack frame and the top-most initial kernel one.
      Reported-by: NMeelis Roos <mroos@linux.ee>
      Tested-by: NMeelis Roos <mroos@linux.ee>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ef3e035c
  2. 24 10月, 2014 22 次提交
  3. 23 10月, 2014 15 次提交