Re: [PATCH 0/5] stack overflow safe kdump (2.6.15-i386)

[Vivek Goyal <vgoyal@in.ibm.com>]

On Thu, Jan 19, 2006 at 03:07:55PM +0900, Fernando Luis Vazquez Cao wrote:
> > >    -> Regarding the implementation, I have some doubts:
> > >       - Should the NMI vector replaced atomically?
> > >       - Should the NMI watchdog be stopped? Should NMIs be disabled in the crash
> > >         path of each CPU?
> > >       This is important because after replacing the nmi handler the NMI
> > >       watchdog will continue generating interrupts that need to be handled
> > >       properly. If we can avoid this a kdump-specific nmi vector handler
> > >       (ENTRY(crash_nmi)) could be safely used.
> > 
> > Can we have something like per cpu flag which will be set if NMI is received
> > after crash (after replacing the trap vector). If another NMI occurs on 
> > the same cpu and if flag is set, return and don't process it further.
> The problem is that when one CPU crashes in a SMP system and the NMI
> watchdog is enabled, the others will continue receiving NMI from the
> watchdog and will eventually also receive the NMI from the crashing CPU.
> The NMI handler has to be able to process both adequately if we cannot
> stop the NMI watchdog atomically. Even if we used such a flag we would
> need to figure out the originator of the NMI.
> 

Well, once system has crashed we have replaced the NMI callback with
crash_nmi_callback(), I would tend to think that there might not be 
any need to differentiate between various NMIs.

Though disabling other NMIs is the right way to handle it, but if there is
no straight easy way to do that then, even if I executed the
crash_nmi_callback() due to NMI originating from other source than NMI IPI
from crashing cpu, probably should be ok.