[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20140131134345.0d63bce0fc19d5fe86541e13@linux-foundation.org>
Date: Fri, 31 Jan 2014 13:43:45 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Michel Lespinasse <walken@...gle.com>
Cc: Frédéric Weisbecker <fweisbec@...il.com>,
Salman Qazi <sqazi@...gle.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: Reverting warning for vmalloc and kmemcheck faults in NMI
On Thu, 30 Jan 2014 19:06:58 -0800 Michel Lespinasse <walken@...gle.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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists