Time is set to UNIX epoch due to `read_persistent_clock` being renamed to `read_persistent_clock64`

[Roberto Frenna]

Hi! I have been debugging a timing related issue recently which led me to investigate the matter further, and I found out the following.

In 9266178, read_persistent_clock was removed during the shift to 64 bit timestamps as it was no longer used, in an effort to prevent the Y38K problem.

However, this change was never noticed downstream in the LKL repo, where the 32-bit read_persistent_clock is still implemented, and never being used. The reason why no error is thrown even though the original function was renamed is because read_persistent_clock64 has the __weak descriptor, so the kernel is silently using the default implementation:

https://github.com/lkl/linux/blob/8a1fc6c/kernel/time/timekeeping.c#L1476-L1489

All of this has caused the issue described in #158 to happen again -- i.e., the userspace kernel is not synchronizing its time with the host anymore, and starts its wall clock time from the UNIX epoch.

[Hajime Tazaki]

thanks for the report. We should/will fix this.