On Fri, Aug 14, 2020 at 12:54:35PM +0530, Sumit Garg wrote: > On Thu, 13 Aug 2020 at 05:30, Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > > On Tue, Jul 21, 2020 at 5:10 AM Sumit Garg <sumit.garg@xxxxxxxxxx> wrote: > > Wishful thinking, but (as far as I can tell) irq_work_queue() only > > queues work on the CPU running the NMI. I don't have lots of NMI > > experience, but any chance there is a variant that will queue work on > > any CPU? Then sysrq handlers that aren't NMI aware will be more > > likely to work. > > > > Unfortunately, queuing work on other CPUs isn't safe in NMI context, > see this warning [1]. The comment mentions: > > /* Arch remote IPI send/receive backend aren't NMI safe */ > > Peter, > > Can you throw some light here as to why it isn't considered NMI-safe > to send remote IPI in NMI context? Is it an arch specific limitation? Yeah, remote irq_work uses __smp_call_single_queue() / send_call_function_single_ipi() which isn't safe to be used from NMI context in general. arch_irq_work_raise() is very carefully implemented on a number of platforms to be able to (self) IPI from NMI context.