Skip to content
  • David S. Miller's avatar
    sparc64: Fix register corruption in top-most kernel stack frame during boot. · ef3e035c
    David S. Miller authored
    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: default avatarMeelis Roos <mroos@linux.ee>
    Tested-by: default avatarMeelis Roos <mroos@linux.ee>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    ef3e035c