Re: gettimeofday question

[Eli Carter]

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.