Messages in this thread | | | From | John Stultz <> | Date | Thu, 24 Aug 2023 21:02:45 -0700 | Subject | Re: [RFC PATCH v2 2/6] timekeeping: Fix cross-timestamp interpolation corner case decision |
| |
On Thu, Aug 17, 2023 at 6:20 PM Peter Hilber <peter.hilber@opensynergy.com> wrote: > > The cycle_between() helper checks if parameter test is in the open interval > (before, after). Colloquially speaking, this also applies to the counter > wrap-around special case before > after. get_device_system_crosststamp() > currently uses cycle_between() at the first call site to decide whether to > interpolate for older counter readings. > > get_device_system_crosststamp() has the following problem with > cycle_between() testing against an open interval: Assume that, by chance, > cycles == tk->tkr_mono.cycle_last (in the following, "cycle_last" for > brevity). Then, cycle_between() at the first call site, with effective > argument values cycle_between(cycle_last, cycles, now), returns false, > enabling interpolation. During interpolation, > get_device_system_crosststamp() will then call cycle_between() at the > second call site (if a history_begin was supplied). The effective argument > values are cycle_between(history_begin->cycles, cycles, cycles), since > system_counterval.cycles == interval_start == cycles, per the assumption. > Due to the test against the open interval, cycle_between() returns false > again. This causes get_device_system_crosststamp() to return -EINVAL. > > This failure should be avoided, since get_device_system_crosststamp() works > both when cycles follows cycle_last (no interpolation), and when cycles > precedes cycle_last (interpolation). For the case cycles == cycle_last, > interpolation is actually unneeded. > > Fix this by disabling interpolation if cycles == cycle_last. Thereby, avoid > the above described corner case interpolation failure. > > Fixes: 2c756feb18d9 ("time: Add history to cross timestamp interface supporting slower devices") > Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com>
Thanks for respinning these. It's still a little tough to get my head around why this is needed, but the extra explanation helps a lot!
Acked-by: John Stultz <jstultz@google.com>
| |