APPLIED: [SRU][X][PATCH 0/1] clock: overriding the clocksource should select the requested clocksource

William Breathitt Gray william.gray at canonical.com
Thu Sep 17 13:38:13 UTC 2020


On Mon, Sep 07, 2020 at 04:15:27PM +1200, Matthew Ruffell wrote:
> BugLink: https://bugs.launchpad.net/bugs/1894591
> 
> [Impact]
> 
> The default clocksource for a KVM VM is kvm-clock, and I happen to need tsc.
> 
> $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource 
> kvm-clock
> 
> If I edit /etc/default/grub and append "clocksource=tsc" to 
> GRUB_CMDLINE_LINUX_DEFAULT and reboot, I find the clocksource is still kvm-clock.
> 
> $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource 
> kvm-clock
> 
> I can work around this by telling the kernel that the tsc clocksource is 
> reliable, before the watchdog has a chance to see for itself that it is reliable:
> 
> GRUB_CMDLINE_LINUX_DEFAULT="clocksource=tsc tsc=reliable"
> 
> $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource 
> tsc
> 
> If I override the clocksource, the kernel should respect my wishes and I should 
> receive the requested clocksource.
> 
> [Fix]
> 
> The fix landed in Linux 4.9 in the below commit:
> 
> commit 36374583f9084cdab4b5dcf5521a3ce55bebb9fa
> Author: Kyle Walker <kwalker at redhat.com>
> Date:   Sat Aug 6 12:07:30 2016 -0400
> Subject: clocksource: Defer override invalidation unless clock is unstable
> Link: https://github.com/torvalds/linux/commit/36374583f9084cdab4b5dcf5521a3ce55bebb9fa 
> 
> The commit ensures the override doesn't get cleared before the watchdog has had
> an opportunity to check if the clocksource is stable or not. However, if the 
> clocksource is known to be unstable at this point in time, it will clear the 
> override and return to the default.
> 
> This is a clean cherry-pick to the Xenial 4.4 kernel.
> 
> [Testcase]
> 
> Start up a KVM VM, possibly enable invtsc on the QEMU command line.
> 
> The default clocksource will be kvm-clock:
> 
> $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource 
> kvm-clock
> 
> If you set the kernel command line to:
> 
> GRUB_CMDLINE_LINUX_DEFAULT="clocksource=tsc"
> 
> If you reboot, you will see the incorrect option of kvm-clock:
> 
> $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource 
> kvm-clock
> 
> There is a test kernel available in the below ppa, with the commit applied:
> 
> https://launchpad.net/~mruffell/+archive/ubuntu/sf291501-test 
> 
> If you install the test kernel, and leave the kernel command line as:
> 
> GRUB_CMDLINE_LINUX_DEFAULT="clocksource=tsc"
> 
> You will get the requested clocksource:
> 
> $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource 
> tsc
> 
> You will also get the following in dmesg:
> 
> $ dmesg | grep defer
> [    1.002599] clocksource: Override clocksource tsc is not currently HRT compatible - deferring
> 
> [Regression Potential]
> 
> This commit changes how the kernel treats clocksource overrides. If any users
> have an override set, but the kernel is clearing the override and returning to
> the default, when they install a patched kernel, they will change over to their 
> requested override, which may come as a surprise.
> 
> If there is a regression, it will only affect systems who have clocksource 
> overrides in place, and in the worst case, will revert the system to its default
> clocksource if the selected clocksource override is found to be unstable.
> 
> The commit is well tested, and should not cause any regressions.
> 
> Kyle Walker (1):
>   clocksource: Defer override invalidation unless clock is unstable
> 
>  kernel/time/clocksource.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> -- 
> 2.25.1

Applied to Xenial.

William Breathitt Gray
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20200917/1fb996a5/attachment.sig>


More information about the kernel-team mailing list