On Tue 2016-08-30 18:39:18, Sergey Senozhatsky wrote: > On (08/30/16 11:04), Petr Mladek wrote: > > On Tue 2016-08-30 16:58:34, Sergey Senozhatsky wrote: > > > Petr, > > > one more question. Not related to the patch, but still related to NMI. > > > > > > can NMI nest? > > > > AFAIK, they cannot. NMIs should be disabled until iret is called. > > Therefore we should be on the safe side if iret is not called > > inside the NMI handler. But this should not happen because > > it would cause other problems, like using wrong return address. > > > > Well, x86 nmi code has some hacks to handle exceptions inside > > NMI handlers that use iret. But printk_nmi_enter()/printk_nmi_exit() > > are never nested there. It is prevented by the nmi_state per-CPU > > variable. See do_nmi() in arch/x86/kernel/nmi.c. > > yes, x86 has a per-cpu nmi_state to handle the case when NMI is > loosing its NMI context. But other arch-s, as far as I can see, > don't do that. Does it mean that we are safe only on x86?
My understanding is that the kernel would crash on the other architectures if a double iret was called. By other words, they would have bigger problems than the nmi_enter()/nmi_exit() calls. So, we should be on the safe side. > this printk_func_saved thing is still will be needed, I think, > for alt_printk. > > Example: > > process abc > printk() > alt_printk_enter() > this_cpu_write(printk_func, vprintk_alt); > -> NMI > : printk_nmi_enter() > : this_cpu_write(printk_func, vprintk_nmi); > : printk_nmi_exit() > : this_cpu_write(printk_func, vprintk_default); > return NMI > > printk() <<<< nested printk -> vprintk_default(), set by > nmi_exit() > alt_printk_exit() > ... I see. But then we will need to be more careful because printk_func and printk_func_saved will be manipulated in different contexts: normal, irq, nmi. A solution might be using an atomic counter and selecting the right vprintk_func according to the value. Well, I am still afraid that yet another alt_printk is not the way to go. Best Regards, Petr
