linux-kernel - Re: [PATCH v7] sched/clock: Avoid false sharing for sched_clock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a9ece3cf-c6bf-4bfb-be2d-0838a23e6708@amd.com>
Date: Wed, 28 Jan 2026 12:48:39 +0530
From: K Prateek Nayak <kprateek.nayak@....com>
To: Shrikanth Hegde <sshegde@...ux.ibm.com>, "Guo, Wangyang"
	<wangyang.guo@...el.com>
CC: <linux-kernel@...r.kernel.org>, Benjamin Lei <benjamin.lei@...el.com>, Tim
 Chen <tim.c.chen@...ux.intel.com>, Tianyou Li <tianyou.li@...el.com>, Ingo
 Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>, Juri Lelli
	<juri.lelli@...hat.com>, Vincent Guittot <vincent.guittot@...aro.org>,
	Dietmar Eggemann <dietmar.eggemann@....com>, Steven Rostedt
	<rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>, Mel Gorman
	<mgorman@...e.de>, Valentin Schneider <vschneid@...hat.com>
Subject: Re: [PATCH v7] sched/clock: Avoid false sharing for
 sched_clock_irqtime

On 1/28/2026 11:56 AM, Shrikanth Hegde wrote:
> 
> 
> On 1/28/26 8:35 AM, K Prateek Nayak wrote:
>> On 1/28/2026 7:49 AM, Guo, Wangyang wrote:
>>> Yes, when clock mark unstable through tsc_.*mark_unstable() with non-native_sched_clock, clear_sched_clock_stable won't be called, thus sched_clock_irqtime still keep enabled.
>>>
>>> Maybe the dedicated workqueue for sched_clock_irqtime is still needed considering this case.
>>
>> In that case, shouldn't tsc_init() only enable irqtime when
>> using_native_sched_clock()? How can tsc_init() make a call on irqtime if
>> TSC isn't being used as the sched_clock() ultimately?
>>
>> For kvmclock, if PVCLOCK_TSC_STABLE_BIT is not set, it'll call
>> clear_sched_clock_stable() at kvm_sched_clock_init() but none of the
>> other clocksources do so we can assume once we override the sched_clock()
>> it is up to the sched_clock() provider to deal with the clock stability.
>>
> 
> I think this would depend if mark_tsc_unstable happens after system boot,
> specially while running kvm guest?

I don't see anything on the guest side that would mark the kvmclock as
unstable if host's TSC turns unstable post init and since kvmclock
doesn't set CLOCK_SOURCE_MUST_VERIFY, I doubt if a watchdog runs to
verify it in the guest.

I have the following in the guest:

    $ sudo dmesg | grep -i clock
    [    0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00
    [    0.000000] kvm-clock: using sched offset of 423259259 cycles
    [    0.000002] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
    [    0.071675] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
    [    0.378467] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns
    [    0.388678] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x398cb1e4d56, max_idle_ns: 881590790753 ns
    [    0.679262] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
    [    0.903121] PTP clock support registered
    [    0.927243] clocksource: Switched to clocksource kvm-clock
    [    0.944986] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
    [    0.993198] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x398cb1e4d56, max_idle_ns: 881590790753 ns
    [    1.123796] rtc_cmos 00:05: setting system clock to 2026-01-28T07:03:45 UTC (1769583825)
    [    1.155755] sched_clock: Marking stable (940009972, 212965288)->(1171254846, -18279586)
    [    1.712598] clk: Disabling unused clocks

Then I mark TSC unstable on the host

    tsc: Marking TSC unstable due to Faking unreliable TSC!
    TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.
    clocksource: Checking clocksource tsc synchronization from CPU 93 to CPUs 0,2,26,75,101,114,118,195.
    sched_clock: Marking unstable (945948313746, 69389667)<-(947618130068, -1600430832)
    clocksource:         CPU 93 check durations 3436ns - 25277ns for clocksource tsc.
    clocksource: Switched to clocksource hpet

And nothing happens in the guest.

    cat /sys/devices/system/clocksource/clocksource0/current_clocksource
    kvm-clock


If I launch the guest after marking host TSC unstable, I see:

    Unstable clock detected, switching default tracing clock to "global"

and I don't get any "sched_clock: Marking stable" messages.

-- 
Thanks and Regards,
Prateek