Miklos reported [1] that the recent VDSO changes broke paravirt clocksource
based VDSO in the case that the clocksource is invalidated by the
hypervisor which happens after a suspend/resume cycle of the host.
The result is a stale clocksource which is about 2200 seconds ahead of the
actual time and jumps forward by 2200 seconds once 2200 seconds have
elapsed.
The reason for this is the core code change which optimized the VDSO
clocksource validation by checking for the clocksource mode instead of
using the rather subtle check for the clocksource read return value whether
it has bit 63 set.
For some reason my brain blanked when doing that change, even if I should
have known better.
The following series restores the previous behaviour but preserves the
initially intended optimization for architectures which don't need that PV
handling.
Thanks,
tglx
[1] https://lore.kernel.org/r/CAJfpegstNYeseo_C4KOF9Y74qRxr78x2tK-9rTgmYM4CK30nRQ@mail.gmail.com
8<-----------------
arch/x86/include/asm/vdso/gettimeofday.h | 18 ++++++++++++++++++
kernel/time/clocksource.c | 2 --
lib/vdso/gettimeofday.c | 19 +++++++++++++++++++
3 files changed, 37 insertions(+), 2 deletions(-)
On Sun, Jun 7, 2020 at 11:36 AM Thomas Gleixner <[email protected]> wrote:
>
> Miklos reported [1] that the recent VDSO changes broke paravirt clocksource
> based VDSO in the case that the clocksource is invalidated by the
> hypervisor which happens after a suspend/resume cycle of the host.
>
> The result is a stale clocksource which is about 2200 seconds ahead of the
> actual time and jumps forward by 2200 seconds once 2200 seconds have
> elapsed.
>
> The reason for this is the core code change which optimized the VDSO
> clocksource validation by checking for the clocksource mode instead of
> using the rather subtle check for the clocksource read return value whether
> it has bit 63 set.
>
> For some reason my brain blanked when doing that change, even if I should
> have known better.
>
> The following series restores the previous behaviour but preserves the
> initially intended optimization for architectures which don't need that PV
> handling.
Thanks for fixing.
Tested-by: Miklos Szeredi <[email protected]>
Miklos