• Hidetoshi Seto's avatar
    ia64, kdump: Mask INIT first in panic-kdump path · a6e0f2d7
    Hidetoshi Seto authored
    Summary:
    
      Asserting INIT might block kdump if the system is already going to
      start kdump via panic.
    
    Description:
    
      INIT can interrupt anywhere in panic path, so it can interrupt in
      middle of kdump kicked by panic.  Therefore there is a race if kdump
      is kicked concurrently, via Panic and via INIT.
    
      INIT could fail to invoke kdump if the system is already going to
      start kdump via panic.  It could not restart kdump from INIT handler
      if some of cpus are already playing dead with INIT masked.  It also
      means that INIT could block kdump's progress if no monarch is entered
      in the INIT rendezvous.
    
      Panic+INIT is a rare, but possible situation since it can be assumed
      that the kernel or an internal agent decides to panic the unstable
      system while another external agent decides to send an INIT to the
      system at same time.
    
    How to reproduce:
    
      Assert INIT just after panic, before all other cpus have frozen
    
    Expected results:
    
      continue kdump invoked by panic, or restart kdump from INIT
    
    Actual results:
    
      might be hang, crashdump not retrieved
    
    Proposed Fix:
    
      This patch masks INIT first in panic path to take the initiative on
      kdump, and reuse atomic value kdump_in_progress to make sure there is
      only one initiator of kdump.  All INITs asserted later should be used
      only for freezing all other cpus.
    
      This mask will be removed soon by rfi in relocate_kernel.S, before jump
      into kdump kernel, after all cpus are frozen and no-op INIT handler is
      registered.  So if INIT was in the interval while it is masked, it will
      pend on the system and will received just after the rfi, and handled by
      the no-op handler.
    
      If there was a MCA event while psr.mc is 1, in theory the event will
      pend on the system and will received just after the rfi same as above.
      MCA handler is unregistered here at the time, so received MCA will not
      reach to OS_MCA and will result in warmboot by SAL.
    
      Note that codes in this masked interval are relatively simpler than
      that in MCA/INIT handler which also executed with the mask.  So it can
      be said that probability of error in this interval is supposed not so
      higher than that in MCA/INIT handler.
    Signed-off-by: default avatarHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
    Cc: Vivek Goyal <vgoyal@redhat.com>
    Cc: Haren Myneni <hbabu@us.ibm.com>
    Cc: kexec@lists.infradead.org
    Acked-by: default avatarFenghua Yu <fenghua.yu@intel.com>
    a6e0f2d7
relocate_kernel.S 7.5 KB