On Sun, Jul 5, 2015 at 9:53 PM, Thomas Gleixner <[email protected]> wrote: > Andriy reported that on a virtual machine the warning about negative > expiry time in the clock events programming code triggered: > > hpet: hpet0 irq 40 for MSI > hpet: hpet1 irq 41 for MSI > Switching to clocksource hpet > WARNING: at kernel/time/clockevents.c:239 > > [<ffffffff810ce6eb>] clockevents_program_event+0xdb/0xf0 > [<ffffffff810cf211>] tick_handle_periodic_broadcast+0x41/0x50 > [<ffffffff81016525>] timer_interrupt+0x15/0x20 > > When the second hpet is installed as a per cpu timer the broadcast > event is not longer required and stopped, which sets the next_evt of > the broadcast device to KTIME_MAX. > > If after that a spurious interrupt happens on the broadcast device, > then the current code blindly handles it and tries to reprogram the > broadcast device afterwards, which adds the period to > next_evt. KTIME_MAX + period results in a negative expiry value > causing the WARN_ON in the clockevents code to trigger. > > Add a proper check for the state of the broadcast device into the > interrupt handler and return if the interrupt is spurious. > > Reported-by: Andriy Gapon <[email protected]> > Signed-off-by: Thomas Gleixner <[email protected]> > --- > kernel/time/tick-broadcast.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > Index: tip/kernel/time/tick-broadcast.c > =================================================================== > --- tip.orig/kernel/time/tick-broadcast.c > +++ tip/kernel/time/tick-broadcast.c > @@ -301,6 +301,13 @@ static void tick_handle_periodic_broadca > bool bc_local; > > raw_spin_lock(&tick_broadcast_lock); > + > + /* Handle spurious interrupts gracefully */ > + if (clockevent_state_shutdown(&tick_broadcast_device.evtdev)) {
I tried this patch along with 1/2, found that this generating warning as tick_broadcast_device.evtdev is of type ‘struct clock_event_device *’ already, so it can be passed directly. Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
