linux-kernel - Re: recent x86-64 nested NMI adjustments

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:	Mon, 12 Mar 2012 10:21:11 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Jan Beulich <JBeulich@...e.com>
Cc:	mingo@...e.hu, Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, hpa@...or.com
Subject: Re: recent x86-64 nested NMI adjustments

On Mon, 2012-03-12 at 13:31 +0000, Jan Beulich wrote:

> Ah, right - the way the new check got placed I (wrongly) implied
> it to guard the immediately succeeding check of the "special
> variable", whereas it really guards (only) test_in_nmi.

The reason I placed it there was because I thought that would be the
more common case. As nested NMIs are the .00001% case, and the variable
check only can prove that we were in a nested NMI, but does not prove we
are not, in which case it would still need to do the other checks.

I figured that a good % of NMIs will interrupt userspace, and let that
be the fast path. When an NMI interrupts userspace, this check will make
it skip the rest of the checks. Seemed to be the logical placement.

But I see where the confusion came from. The placement was for
optimization of the fast path, not for where it *had* to be.

> 
> Thanks for the explanation, and sorry for the noise then.

No prob,

-- Steve

--
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/