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 >
