[PATCH] powerpc: irq work racing with timer interrupt can result in timer interrupt hang
Preeti U Murthy
preeti at linux.vnet.ibm.com
Sun May 11 18:43:56 EST 2014
On 05/11/2014 02:07 PM, Benjamin Herrenschmidt wrote:
> On Sun, 2014-05-11 at 13:45 +0530, Preeti U Murthy wrote:
>> + /* Don't adjust the decrementer if some irq work is pending
>> + if (!test_irq_work_pending())
>> + set_dec(evt);
>> + else
>> + set_dec(1);
>> ^^^^^ your patch currently does not have this
>> set_dec(1) here. Will that create a problem?
>> If there is any irq work pending at this point, will someone set the
>> decrementer to fire immediately after this point? The current code in
>> decrementer_set_next_event() sets set_dec(1) explicitly in case of
>> pending irq work.
> Hrm, actually this is an interesting point. The problem isn't that
> *someone* will do a set_dec, nobody else should that matters.
> The problem is that irq_work can be triggered typically by NMIs or
> similar, which means that it might be queued between the
> test_irq_work_pending() and the set_dec(), thus causing a race.
> So basically Anton's original patch is fine :-) I had missed that
> we did a post-set_dec() test already in decrementer_next_event()
> so as far as I can tell, removing the pre-test, which is what Anton
> does, is really all we need.
Isn't this patch required too?
@@ -503,12 +503,13 @@ void __timer_interrupt(void)
now = *next_tb - now;
if (now <= DECREMENTER_MAX)
- /* We may have raced with new irq work */
- if (test_irq_work_pending())
+ /* We may have raced with new irq work */
+ if (test_irq_work_pending())
The event_handler cannot be relied upon to call
decrementer_set_next_event() all the time. This is in the case where
there are no pending timers. In that case we need to have the check on
irq work pending at the end of __timer_interrupt() no?
Preeti U Murthy
More information about the Linuxppc-dev