Finn,
On Wed, 14 Nov 2018, Finn Thain wrote:
On Tue, 13 Nov 2018, Thomas Gleixner wrote:
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...
arch_gettimeoffset() can be called from any context. The only interrupt
which can affect it is the timer interrupt. As m68k are all UP machines
this is not a problem because:
ktime_get()
do {
seq = read_seqcount_begin(tk.seq);
nsec = .... + arch_gettimeoffset();
} while (seqcount_retry(tk.seq);
and the timer interrupt does:
arch_timeoffset += value;
...
xtime_update()
...
write_seqcount_begin(tk.seq);
....
write_seqcount_end(tk.seq);
So where ever the timer interrupt hits inside of ktime_get() or any other
accessor the seqcount will make it retry, so the result is always
consistent.
For SMP that would be a different story.
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.)
Oh yes, you should.
Thanks,
tglx
