On Tue, 27 Apr 2021 08:54:37 +0800 Lai Jiangshan <jiangshanlai+lkml@xxxxxxxxx> wrote: > > However, I'm not sure which of the two situations is better: entering > > the NMI handler on the IST without setting the hidden NMI-blocked flag > > could be a recipe for bad things as well. > > The change makes the ASM NMI entry called on the kernel stack. But the > ASM NMI entry expects it on the IST stack and it plays with "NMI executing" > variable on the IST stack. In this change, the stranded ASM NMI entry > will use the wrong/garbage "NMI executing" variable on the kernel stack > and may do some very wrong thing. I missed this detail. > > Sorry, in my reply, "the NMI handler" meant to be the ASM entry installed > on the IDT table which really expects to be NMI-masked at the beginning. > > The C NMI handler can handle the case of nested NMIs, which is useful > here. I think we should change it to call the C NMI handler directly > here as Andy Lutomirski suggested: Yes, because that's the way x86_32 works. > > On Mon, Apr 26, 2021 at 11:09 PM Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > > The C NMI code has its own reentrancy protection and has for years. > > It should work fine for this use case. > > I think this is the right way. Agreed. -- Steve
