Messages in this thread | | | Date | Wed, 14 May 2014 22:55:40 -0400 (EDT) | From | Vince Weaver <> | Subject | Re: 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
| |