[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e5e107e7-e18e-725a-8f9b-95e6f033ab45@arm.com>
Date: Thu, 19 Apr 2018 16:35:52 +0100
From: James Morse <james.morse@....com>
To: "Alex G." <mr.nuke.me@...il.com>
Cc: Borislav Petkov <bp@...en8.de>, linux-acpi@...r.kernel.org,
linux-edac@...r.kernel.org, rjw@...ysocki.net, lenb@...nel.org,
tony.luck@...el.com, tbaicar@...eaurora.org, will.deacon@....com,
shiju.jose@...wei.com, zjzhang@...eaurora.org,
gengdongjiu@...wei.com, linux-kernel@...r.kernel.org,
alex_gagniuc@...lteam.com, austin_bolen@...l.com,
shyam_iyer@...l.com, devel@...ica.org, mchehab@...nel.org,
robert.moore@...el.com, erik.schmauss@...el.com
Subject: Re: [RFC PATCH v2 3/4] acpi: apei: Do not panic() when correctable
errors are marked as fatal.
Hi Alex,
(I haven't read through all this yet, just on this one:)
On 04/19/2018 03:57 PM, Alex G. wrote:
> Maybe it's better move the AER handling to NMI/IRQ context, since
> ghes_handle_aer() is only scheduling the real AER andler, and is irq
> safe. I'm scratching my head about why we're messing with IRQ work from
> NMI context, instead of just scheduling a regular handler to take care
> of things.
We can't touch schedule_work_on() from NMI context as it takes spinlocks and
disables interrupts. (see __queue_work()) The NMI may have interrupted
IRQ-context code
that was already holding the same locks.
IRQ-work behaves differently, it uses an llist for the work and an arch
code hook
to raise a self-IPI.
Thanks,
James
Powered by blists - more mailing lists