Re: [PATCH_TAKE_2] now < last_tick problem

David Mosberger
2003-10-10T16:42:35Z

Ian,

Just a quick note (got to run): I think you correctly identified the
race causing the now < last_tick problem. Purely from (bad) memory, I
think the problem was introduced when xtime_lock was converted from an
irq-safe spinlock to a seq-lock. In theory, xtime_lock still protects
get_offset(), but the theory only holds as long as the seq-lock body
is "transactional" (no side-effects until read_seqretry() returns 0).
I think the source of the probem is that we consider the value
returned by get_offset() to be valid EVEN when read_seqretry() returns
1. Because of that, we'll end up updating last_nsec_offset with a
potentialy bad value.

--david