lkml.org 
[lkml]   [2014]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: perfevents: irq loop stuck!
On Tue, 13 May 2014, Vince Weaver wrote:

> pe[32].sample_period=0xc0000000000000bd;
>
> Should it be possible to open an event with a large negative sample_period
> like that?

so this seems to be a real bug.

attr->sample_period is a u64 value, but internally it gets cast to
s64 and is added against itself and so all kinds of unexpected things
happen.

So if you set attr->sample_period to 0xc0000000000000bd in the hopes of
sampling the RETIRED_INSTRUCTIONS event every 5 years or so, instead
what happens is that in
x86_perf_event_set_period()
the value is cast to a signed 64-bit value, so we are now negative.

Then "left" is set to period because we are negative.

Then since left is less than 0, we double the period value.
This overflows the 64-bit integer and suddenly we are in undefined
behavior territory and we're lucky the C compiler doesn't decide to
format the hard drive.

Anyway we are still less than 0, so then the

if (unlikely(left < 2))
left = 2;

code kicks in and suddenly our hugely positive sample_period has changed
to just being "2". And so we suddenly get a storm of interrupts instead
of one every 5 years.

So, not sure how to fix this without a total re-write, unless we want to
cheat and just say sample_period is capped at 62-bits or something.

Also it's unclear why sometimes this can cause a stuck interrupt leading
to the "irq loop stuck" message. I have a reproducible fuzzer test case
that will cause this to happen, but can't isolate it down to a simple test
case...

Vince



\
 
 \ /
  Last update: 2014-05-15 05:41    [W:0.239 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site