tick/broadcast: Handle spurious interrupts gracefully
tick/broadcast: Handle spurious interrupts gracefully

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.

[ Folded in pointer fix from Sudeep ]

Reported-by: Andriy Gapon <97e77871b5fcc4941bebceb4338c97c1fd149f8c@FreeBSD.org>
Signed-off-by: Thomas Gleixner <00e4cf8f46a57000a44449bf9dd8cbbcc209fd2a@linutronix.de>
Cc: Sudeep Holla <2f8b50d4d9838571c9f6955972f29e9e41079295@arm.com>
Cc: Peter Zijlstra <3fddac958924aef220f202ca567388ddab3f14a8@infradead.org>
Cc: Preeti U Murthy <437f8f4633f3d09bf55bbcfb98d29bc10a99c7d0@linux.vnet.ibm.com>
Link: 26c896ecbb841baa74bd69e04342cb3bf10e09e0@linutronix.de

KristFoundation/Programs,KristFoundation/Programs,KristFoundation/Programs,KristFoundation/Programs,KristFoundation/Programs,KristFoundation/Programs