linux-kernel - Re: [PATCH] x86, perf, bts: disable BTS from Nehalem to Ivy Bridge

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 24 Jan 2013 16:46:37 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	markus.t.metzger@...el.com
Cc:	mingo@...hat.com, mingo@...e.hu, linux-kernel@...r.kernel.org,
	Mark Kettenis <kettenis@....org>,
	Pedro Alves <palves@...hat.com>,
	Jan Kratochvil <jan.kratochvil@...hat.com>,
	gdb-patches@...rceware.org
Subject: Re: [PATCH] x86, perf, bts: disable BTS from Nehalem to Ivy Bridge


* markus.t.metzger@...el.com <markus.t.metzger@...el.com> wrote:

> From: Markus Metzger <markus.t.metzger@...el.com>
> 
> Starting with Nehalem, the BTS "from" information may in some cases be
> incorrect (AAJ122).
> 
> This has been detected while adding branch tracing support to gdb, where it
> results in sporadic test fails.
> 
> Disable BTS support on Nehalem, Westmere, Sandy Bridge, and Ivy Bridge.

But the failures are rare, so the BTS data is still correct 
statistically, by and large, right? So why not just keep it 
as-is and teach tooling to be more robust about implausible 
trace entries? It has to be ready for that eventuality *anyway*.

Thanks,

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