Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Time is set to UNIX epoch due to read_persistent_clock being renamed to read_persistent_clock64 #488

Open
Robertof opened this issue Apr 29, 2020 · 1 comment
Open

Time is set to UNIX epoch due to read_persistent_clock being renamed to read_persistent_clock64 #488

Robertof opened this issue Apr 29, 2020 · 1 comment
Labels
in_fix_queue will fix in next release

Comments

@Robertof
Copy link

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.
@Robertof Robertof mentioned this issue Apr 30, 2020
Closed
10 tasks
Robertof added a commit to Robertof/nixpkgs that referenced this issue Apr 30, 2020
@Robertof
nixos/lib/make-ext4-fs: always allow execution of resize2fs
115ccd5 
Without the `-f` flag, `resize2fs` checks that the last time where the
filesystem was checked is greater or equal than the last time is mounted.
This currently works due to a bug in `cptofs`
(lkl/linux#488) and it breaks on slower systems
when the last mount time is greater than 1970-01-01 00:00:01.

To fix this, either we allow `fsck` to update the "last checked" timestamp
on the filesystem, which requires to replace the `-n` option with `-y`,
or we force `resize2fs` to skip these checks. Since we're only dealing
with an image file which is checked immediately before resizing, it is
safe to bypass this check as `fsck` will fail if the filesystem is unclean.
@thehajime thehajime added the in_fix_queue will fix in next release label May 1, 2020
@thehajime
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
in_fix_queue will fix in next release
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Robertof @thehajime