On Tue, 13 Nov 2018, Thomas Gleixner wrote:
On Wed, 14 Nov 2018, Finn Thain wrote:
What I mean by that is, the interrupt level (IPL) prevents interrupt
handlers from being re-entered. But a handler can still get
interrupted by a higher priority interrupt request. In the past I've
had to add defensive locking because of this.
In these patches I've assumed it was possible for some higher priority
interrupt handler to perform a clocksource read after the timer
handler started executing. Hence the use of local_irq_save/restore.
To be sure, I've just run a quick test and confirmed that the timer
handler can indeed get interrupted by the ethernet interrupt handler.
Urgh. Then you have more serious trouble. If the interrupting handler
calls any of the time accessor functions then you can actually live lock
when the interrupt happens in the middle of the write locked section of
the core timekeeping update.
Does this apply to arch_gettimeoffset also? If so, that would mean another
bug fix patch for -stable...
So you really want to disable interrupts across the whole timer
interrupt function or make sure that the timer interrupt is the highest
priority one on the system.
The timer interrupt priority isn't always what one would hope.
But I can certainly disable interrupts for timer_interrupt() execution
(that is, xtime_update() etc.)
--
Thanks,
tglx
