linux-kernel - Re: [PATCH 3/5] perf, x86: Disable PEBS on clowertown chips

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:	Fri, 5 Mar 2010 13:57:49 -0800
From:	Stephane Eranian <eranian@...gle.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	mingo@...e.hu, linux-kernel@...r.kernel.org, paulus@...ba.org,
	robert.richter@....com, fweisbec@...il.com,
	Arnaldo Carvalho de Melo <acme@...radead.org>
Subject: Re: [PATCH 3/5] perf, x86: Disable PEBS on clowertown chips

On Fri, Mar 5, 2010 at 1:43 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Fri, 2010-03-05 at 13:38 -0800, Stephane Eranian wrote:
>> On Fri, Mar 5, 2010 at 1:35 PM, Peter Zijlstra <peterz@...radead.org> wrote:
>> > On Fri, 2010-03-05 at 13:22 -0800, Stephane Eranian wrote:
>> >> > The two serious ones, AJ106 and AJ68 are no fix and are listed as such
>> >> > in all errata I can find, including the 7[23]00 series.
>> >> >
>> >> Not E74xx. I think it would be fine to drop LBR with PEBS as the work-around
>> >> to AJ106.
>> >>
>> >> > I checked the 65nm Core2Duo, Xeon 5200 and Xeon 7[23]00 spec updates.
>> >> > Going by that it seems the full model 15 family is broken and I'll leave
>> >> > the patch as is.
>> >>
>> >> But the E74xx are okay and you are excluding them. Worst case you should
>> >> provide an override.
>> >
>> > >From what I can tell E74xx is model 29, which would be just fine with
>> > this patch, this patch only marks model 15 as broken.
>> >
>> True, my bad.
>> So it would be a matter to provide some ways of disabling LBR with PEBS
>> on model 15.
>
> And some way of dealing with the flaky PEBS PMI, which requires we
> program the pebs_event_reset thing otherwise there won't be a next PEBS
> record to re-trigger the PMI.
>
> If it would have stated it always did the threshold comparison first and
> then the index increment, so that we'd always trigger on the second
> record we could simply program half the period and always take two and
> ignore the first, but it says _MAY_, so its a race and there's no
> reliable solution.
>
> It might all be possible but I don't see it being worth the effort.
>
There are lots of model15 out there, like the Q6xxx series.

When I read AJ68, my understanding is that it's not that you do not
get the interrupt. It will be delayed by one event. The buffer will become
full. You won't overrun the buffer, you will get the interrupt at the next
event. On interrupt, you have to reset the PEBS position pointer anyway.
There is already a disconnect between the sampling period and the actual
instruction sampled. That's not making the situation that much worse, unless
I am missing something.
--
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/