Russell King wrote:
>
> Eli Carter writes:
> > What are you seeing that I'm missing?
>
> Ok, after sitting down and thinking again about this problem, its not
> the 9.9999ms case, but the 10.000000001 case:
And you described (in much better detail) the same problem I was talking
about in the first email I sent today.
gettimeoffset does not handle cases >10ms.
> Like I say, this requires good timing to create, so may not be too much of
> a problem, but it does seem to be a problem that could occur.
You should be able to create this "maliciously" within the kernel (or
with bad driver code...) with something like:
Disable interrupts for 10ms, then call gettimeofday, reenable
interrupts, then call gettimeofday.
(I think.)
> I'm wondering if something like the following will plug this hole:
Yes, but it digs another to get the dirt to fill the first one. :/ for
instance:
>
> read_lock_xtime_and_ints();
> jiffies_1 = jiffies;
> counter_1 = counter;
> read_unlock_xtime_and_ints();
Time passes due to an interrupt handler.... but not a full jiffy, so
jiffies hasn't changed.
Also, what if this function is called with interrupts disabled? (Is
that legal?) If so, we've broken the locking expected by the caller.
> read_lock_xtime_and_ints();
And just for giggles, the counter rolls over here. (And with interrupts
disabled, jiffies isn't updated yet...)
> jiffies_2 = jiffies;
> counter_2 = counter;
> read_unlock_xtime_and_ints();
>
> if (jiffies_1 != jiffies_2) {
> /*
> * we rolled over while reading counter_1. Therefore
> * we can't trust it. Use *_2 instead. Note that we
> * would have received an interrupt between read_unlock
> * and read_lock.
> */
> jiffies_1 = jiffies_2;
> counter_1 = counter_1;
> } else {
> /*
> * we didn't roll over while reading counter_1
> * we can safely use counter_1 as is. Neither
> * did we receive a timer interrupt between the
> * read_unlock and read_lock.
> */
> }
>
> /* apply standard counter correction factor */
Which might be just less than 10ms inaccurate due to that interrupt
handler that ran after we read the times. So we are no more accurate
than before. :/
Unless you use counter_2, but then you have the original problem again.
> The only thing I haven't looked at is whether xtime would be updated.
That is updated in the timer bottom half; jiffies and lost_ticks are
updated in the timer interrupt. lost_ticks is then used by the bottom
half to update xtime. (That's why the gettimeofday portion references
lost_ticks.)
Comments?
Eli
-----------------------. Rule of Accuracy: When working toward
Eli Carter | the solution of a problem, it always
eli.carter(at)inet.com `------------------ helps if you know the answer.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
