diff options
author | Paul Mackerras <paulus@samba.org> | 2010-04-13 20:46:04 +0000 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@suse.de> | 2010-05-26 14:29:16 -0700 |
commit | 73ef533de7533fcf514403125a0d4747d3390317 (patch) | |
tree | 83865693cb3792ac3b358733cf8203b6a820eeee /fs | |
parent | fa157eec79e78a875790df6faf53b3501c33a462 (diff) | |
download | lwn-73ef533de7533fcf514403125a0d4747d3390317.tar.gz lwn-73ef533de7533fcf514403125a0d4747d3390317.zip |
powerpc/perf_event: Fix oops due to perf_event_do_pending call
commit 0fe1ac48bef018bed896307cd12f6ca9b5e704ab upstream.
Anton Blanchard found that large POWER systems would occasionally
crash in the exception exit path when profiling with perf_events.
The symptom was that an interrupt would occur late in the exit path
when the MSR[RI] (recoverable interrupt) bit was clear. Interrupts
should be hard-disabled at this point but they were enabled. Because
the interrupt was not recoverable the system panicked.
The reason is that the exception exit path was calling
perf_event_do_pending after hard-disabling interrupts, and
perf_event_do_pending will re-enable interrupts.
The simplest and cleanest fix for this is to use the same mechanism
that 32-bit powerpc does, namely to cause a self-IPI by setting the
decrementer to 1. This means we can remove the tests in the exception
exit path and raw_local_irq_restore.
This also makes sure that the call to perf_event_do_pending from
timer_interrupt() happens within irq_enter/irq_exit. (Note that
calling perf_event_do_pending from timer_interrupt does not mean that
there is a possible 1/HZ latency; setting the decrementer to 1 ensures
that the timer interrupt will happen immediately, i.e. within one
timebase tick, which is a few nanoseconds or 10s of nanoseconds.)
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'fs')
0 files changed, 0 insertions, 0 deletions