* Reverting warning for vmalloc and kmemcheck faults in NMI
@ 2014-01-31 3:06 Michel Lespinasse
2014-01-31 21:43 ` Andrew Morton
0 siblings, 1 reply; 2+ messages in thread
From: Michel Lespinasse @ 2014-01-31 3:06 UTC (permalink / raw)
To: Frédéric Weisbecker, Salman Qazi; +Cc: LKML, Andrew Morton
Hi,
Way back in 2010, Frederic added commit
ebc8827f75954fe315492883eee5cb3f355d547d to warn us about cases where
faults were incorrectly firing during NMI handling on x86, as the IRET
from such faults would possibly trigger nested NMIs.
Later (2012), Salman added commit
28696f434fef0efa97534b59986ad33b9c4df7f8 to enable nested NMI
handling. See http://lwn.net/Articles/484932/
So, I believe such faults nesting under NMI are not an issue anymore,
and we could revert ebc8827f75954fe315492883eee5cb3f355d547d ?
Background: I'm asking this because at Google we like to dump memory
regions pointed by registers in our arch_trigger_all_cpu_backtrace
handler, and this occasionally causes the vmalloc_fault in_nmi()
warning to fire.
Patch is trivial, I can send it up for review if people don't object
to the idea.
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Reverting warning for vmalloc and kmemcheck faults in NMI
2014-01-31 3:06 Reverting warning for vmalloc and kmemcheck faults in NMI Michel Lespinasse
@ 2014-01-31 21:43 ` Andrew Morton
0 siblings, 0 replies; 2+ messages in thread
From: Andrew Morton @ 2014-01-31 21:43 UTC (permalink / raw)
To: Michel Lespinasse; +Cc: Frédéric Weisbecker, Salman Qazi, LKML
On Thu, 30 Jan 2014 19:06:58 -0800 Michel Lespinasse <walken@google.com> wrote:
> Hi,
>
> Way back in 2010, Frederic added commit
> ebc8827f75954fe315492883eee5cb3f355d547d to warn us about cases where
> faults were incorrectly firing during NMI handling on x86, as the IRET
> from such faults would possibly trigger nested NMIs.
>
> Later (2012), Salman added commit
> 28696f434fef0efa97534b59986ad33b9c4df7f8 to enable nested NMI
> handling. See http://lwn.net/Articles/484932/
>
> So, I believe such faults nesting under NMI are not an issue anymore,
> and we could revert ebc8827f75954fe315492883eee5cb3f355d547d ?
Seems logical.
> Background: I'm asking this because at Google we like to dump memory
> regions pointed by registers in our arch_trigger_all_cpu_backtrace
> handler, and this occasionally causes the vmalloc_fault in_nmi()
> warning to fire.
>
It seems odd that x86 arch_trigger_all_cpu_backtrace() uses NMI - why
didn't it use the regular old IPI? If a CPU is stuck with interrupts
disable, the NMI watchdog will provide the diagnostic?
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2014-01-31 21:43 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-31 3:06 Reverting warning for vmalloc and kmemcheck faults in NMI Michel Lespinasse
2014-01-31 21:43 ` Andrew Morton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).