linux-kernel - Re: Reverting warning for vmalloc and kmemcheck faults in NMI

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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/