lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 14 Aug 2020 16:34:00 +0200
To:     Sumit Garg <>
Cc:     Doug Anderson <>,
        Greg Kroah-Hartman <>,
        Daniel Thompson <>,,,
        Jiri Slaby <>,
        Russell King - ARM Linux <>,
        Jason Wessel <>,
        LKML <>,
        Linux ARM <>
Subject: Re: [RFC 1/5] tty/sysrq: Make sysrq handler NMI aware

On Fri, Aug 14, 2020 at 12:54:35PM +0530, Sumit Garg wrote:
> On Thu, 13 Aug 2020 at 05:30, Doug Anderson <> wrote:
> > On Tue, Jul 21, 2020 at 5:10 AM Sumit Garg <> 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.

Powered by blists - more mailing lists