[V2 PATCH 1/3] x86/panic: Fix re-entrance problem due to panic on NMI
河合英宏 / KAWAI，HIDEHIRO
hidehiro.kawai.ez at hitachi.com
Thu Jul 30 00:33:15 PDT 2015
> From: 河合英宏 / KAWAI，HIDEHIRO [mailto:hidehiro.kawai.ez at hitachi.com]
> > When I was testing my
> > previous approach (on 3.0 based kernel) I had basically the same thing
> > (one NMI to process panic) and others to return. This led to a strange
> > behavior when the NMI button triggered NMI on all (hundreds) CPUs.
> It's strange. Usually, NMI caused by NMI button is routed to only CPU 0
> as an external NMI. External NMI for CPUs other than CPU 0 are masked
> at boot time. Does it really happen? Does the problem still happen on
> the latest kernel? What kind of NMI is deliverd to each CPU?
Are you using SGI UV? On that platform, NMIs may be delivered to
all cpus because LVT1 of all cpus are not masked as follows:
unsigned int value;
* Unmask NMI on all cpus
value = apic_read(APIC_LVT1) | APIC_DM_NMI;
value &= ~APIC_LVT_MASKED;
> Traditionally, we should have assumed that NMI for crash dumping is
> delivered to only one cpu. Otherwise, we should often fail to take
> a proper crash dump. It seems that your case is another problem to be
> solved separately.
> > The
> > crash kernel booted eventually but the log contained lockups when a
> > CPU waited for an IPI to the CPU which was handling the NMI panic.
> Could you explain more precisely?
> > Anyway, I do not thing this is really necessary to solve the panic
> > reentrancy issue.
> > If the missing saved state is a real problem then it
> > should be handled separately - maybe it can be achieved without an IPI
> > and directly from the panic context if we are in NMI.
> What I would like to do via this patchse is to solve race issues
> among NMI, panic() and crash_kexec(). So, I don't think we should fix
> that separately, although I would need to reword some descriptions
> and titles.
> Anyway, I'm going to sent out my revised version once in order to
> tidy up. I also would like to hear kexec/kdump guys' opinions.
More information about the kexec