- Kernel - mailweb.openeuler.org

[openeuler:OLK-6.6 2220/2220] kernel/sched/fair.c:7080:6: sparse: sparse: symbol 'free_affinity_domains' was not declared. Should it be static?
by kernel test robot 13 May '25

13 May '25

Hi Wang, First bad commit (maybe != root cause): tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 196f295c5eeefa026912137e7fc120f3c8565d2e commit: 1a553561230ab6bdc36f9e28e268c75b96dbe67e [2220/2220] sched: smart grid: init sched_grid_qos structure on QOS purpose config: x86_64-randconfig-123-20250513 (https://download.01.org/0day-ci/archive/20250513/202505132224.plUhY3K3-lkp@…) compiler: clang version 20.1.2 (https://github.com/llvm/llvm-project 58df0ef89dd64126512e4ee27b4ac3fd8ddf6247) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250513/202505132224.plUhY3K3-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202505132224.plUhY3K3-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) kernel/sched/fair.c:151:14: sparse: sparse: symbol 'sysctl_overload_detect_period' was not declared. Should it be static? kernel/sched/fair.c:152:14: sparse: sparse: symbol 'sysctl_offline_wait_interval' was not declared. Should it be static? kernel/sched/fair.c:164:14: sparse: sparse: symbol 'sysctl_sched_prio_load_balance_enabled' was not declared. Should it be static? kernel/sched/fair.c:209:5: sparse: sparse: symbol 'sysctl_sched_util_low_pct' was not declared. Should it be static? kernel/sched/fair.c:1310:34: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct sched_entity const *se @@ got struct sched_entity [noderef] __rcu * @@ kernel/sched/fair.c:1310:34: sparse: expected struct sched_entity const *se kernel/sched/fair.c:1310:34: sparse: got struct sched_entity [noderef] __rcu * kernel/sched/fair.c:13907:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] sd @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:13907:9: sparse: expected struct sched_domain *[assigned] sd kernel/sched/fair.c:13907:9: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c:6071:22: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/fair.c:6071:22: sparse: struct task_struct [noderef] __rcu * kernel/sched/fair.c:6071:22: sparse: struct task_struct * >> kernel/sched/fair.c:7080:6: sparse: sparse: symbol 'free_affinity_domains' was not declared. Should it be static? kernel/sched/fair.c:7132:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] tmp @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:7132:9: sparse: expected struct sched_domain *[assigned] tmp kernel/sched/fair.c:7132:9: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c:7146:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] tmp @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:7146:9: sparse: expected struct sched_domain *[assigned] tmp kernel/sched/fair.c:7146:9: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c:7275:38: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct task_struct *curr @@ got struct task_struct [noderef] __rcu *curr @@ kernel/sched/fair.c:7275:38: sparse: expected struct task_struct *curr kernel/sched/fair.c:7275:38: sparse: got struct task_struct [noderef] __rcu *curr kernel/sched/fair.c:8658:20: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] sd @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:8658:20: sparse: expected struct sched_domain *[assigned] sd kernel/sched/fair.c:8658:20: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c:9010:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] tmp @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:9010:9: sparse: expected struct sched_domain *[assigned] tmp kernel/sched/fair.c:9010:9: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c:9122:38: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct task_struct *curr @@ got struct task_struct [noderef] __rcu *curr @@ kernel/sched/fair.c:9122:38: sparse: expected struct task_struct *curr kernel/sched/fair.c:9122:38: sparse: got struct task_struct [noderef] __rcu *curr kernel/sched/fair.c:9468:22: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/fair.c:9468:22: sparse: struct task_struct [noderef] __rcu * kernel/sched/fair.c:9468:22: sparse: struct task_struct * kernel/sched/fair.c:9553:1: sparse: sparse: symbol 'qos_smt_expell_switch' was not declared. Should it be static? kernel/sched/fair.c:9687:51: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct task_struct *sibling_p @@ got struct task_struct [noderef] __rcu *curr @@ kernel/sched/fair.c:9687:51: sparse: expected struct task_struct *sibling_p kernel/sched/fair.c:9687:51: sparse: got struct task_struct [noderef] __rcu *curr kernel/sched/fair.c:9692:30: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/fair.c:9692:30: sparse: struct task_struct [noderef] __rcu * kernel/sched/fair.c:9692:30: sparse: struct task_struct * kernel/sched/fair.c:9770:48: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct task_struct *p @@ got struct task_struct [noderef] __rcu *curr @@ kernel/sched/fair.c:10019:38: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct task_struct *curr @@ got struct task_struct [noderef] __rcu *curr @@ kernel/sched/fair.c:11107:40: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct sched_domain *child @@ got struct sched_domain [noderef] __rcu *child @@ kernel/sched/fair.c:11744:22: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/fair.c:11744:22: sparse: struct task_struct [noderef] __rcu * kernel/sched/fair.c:11744:22: sparse: struct task_struct * kernel/sched/fair.c:13185:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] sd @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:13185:9: sparse: expected struct sched_domain *[assigned] sd kernel/sched/fair.c:13185:9: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c:12842:44: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct sched_domain *sd_parent @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:12842:44: sparse: expected struct sched_domain *sd_parent kernel/sched/fair.c:12842:44: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c:13281:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] sd @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:13281:9: sparse: expected struct sched_domain *[assigned] sd kernel/sched/fair.c:13281:9: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c: note: in included file: kernel/sched/sched.h:2244:25: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/sched.h:2244:25: sparse: struct task_struct [noderef] __rcu * kernel/sched/sched.h:2244:25: sparse: struct task_struct * kernel/sched/sched.h:2408:9: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/sched.h:2408:9: sparse: struct task_struct [noderef] __rcu * kernel/sched/sched.h:2408:9: sparse: struct task_struct * kernel/sched/sched.h:2408:9: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/sched.h:2408:9: sparse: struct task_struct [noderef] __rcu * kernel/sched/sched.h:2408:9: sparse: struct task_struct * kernel/sched/sched.h:2244:25: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/sched.h:2244:25: sparse: struct task_struct [noderef] __rcu * kernel/sched/sched.h:2244:25: sparse: struct task_struct * kernel/sched/sched.h:2244:25: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/sched.h:2244:25: sparse: struct task_struct [noderef] __rcu * kernel/sched/sched.h:2244:25: sparse: struct task_struct * vim +/free_affinity_domains +7080 kernel/sched/fair.c 6eb07f9925a906 Hui Tang 2024-01-17 7079 6eb07f9925a906 Hui Tang 2024-01-17 @7080 void free_affinity_domains(struct affinity_domain *ad) 6eb07f9925a906 Hui Tang 2024-01-17 7081 { 6eb07f9925a906 Hui Tang 2024-01-17 7082 int i; 6eb07f9925a906 Hui Tang 2024-01-17 7083 6eb07f9925a906 Hui Tang 2024-01-17 7084 for (i = 0; i < AD_LEVEL_MAX; i++) { 6eb07f9925a906 Hui Tang 2024-01-17 7085 kfree(ad->domains[i]); 6eb07f9925a906 Hui Tang 2024-01-17 7086 kfree(ad->domains_orig[i]); 6eb07f9925a906 Hui Tang 2024-01-17 7087 ad->domains[i] = NULL; 6eb07f9925a906 Hui Tang 2024-01-17 7088 ad->domains_orig[i] = NULL; 6eb07f9925a906 Hui Tang 2024-01-17 7089 } 6eb07f9925a906 Hui Tang 2024-01-17 7090 ad->dcount = 0; 6eb07f9925a906 Hui Tang 2024-01-17 7091 } 6eb07f9925a906 Hui Tang 2024-01-17 7092 :::::: The code at line 7080 was first introduced by commit :::::: 6eb07f9925a906d81f328c808ba25f7800888dce sched: Introduce smart grid scheduling strategy for cfs :::::: TO: Hui Tang <tanghui20(a)huawei.com> :::::: CC: yanhaitao <yanhaitao2(a)huawei.com> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] kvm: x86: fix infinite loop in kvm_guest_time_update when tsc is 0
by Yuntao Liu 13 May '25

13 May '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IC7KK7 CVE: NA -------------------------------- Fixes: 35181e86df97 ("KVM: x86: Add a common TSC scaling function") Syzkaller testing detected a soft lockup. watchdog: BUG: soft lockup - CPU#3 stuck for 127s! [syz.1.2088:9817] Modules linked in: CPU: 3 PID: 9817 Comm: syz.1.2088 Tainted: G S 6.6.0+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__sanitizer_cov_trace_const_cmp4+0x8/0x20 kernel/kcov.c:313 Code: bf 03 00 00 00 e9 48 fe ff ff 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 48 8b 0c 24 <89> f2 89 fe bf 05 00 00 00 e9 1a fe ff ff 66 2e 0f 1f 84 00 00 00 RSP: 0018:ffff888016d8fad8 EFLAGS: 00000206 RAX: 0000000000080000 RBX: ffff88810e242540 RCX: ffffffff901150d6 RDX: 0000000000080000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff888016d8fb50 R08: 0000000000000001 R09: ffffed1021c484af R10: 0000000000000000 R11: 0000000000000277 R12: 0000000000000000 R13: fffffed357281918 R14: 0000000000000000 R15: 0000000000000001 FS: 00007f2a8f6ea6c0(0000) GS:ffff888119780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000012c56c0 CR3: 000000000dce8001 CR4: 0000000000772ee0 DR0: 0000000000000000 DR1: 0000000000d3eb1c DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> kvm_get_time_scale arch/x86/kvm/x86.c:2458 [inline] kvm_guest_time_update+0x926/0xb00 arch/x86/kvm/x86.c:3268 vcpu_enter_guest.constprop.0+0x1e70/0x3cf0 arch/x86/kvm/x86.c:10678 vcpu_run+0x129/0x8d0 arch/x86/kvm/x86.c:11126 kvm_arch_vcpu_ioctl_run+0x37a/0x13d0 arch/x86/kvm/x86.c:11352 kvm_vcpu_ioctl+0x56b/0xe60 virt/kvm/kvm_main.c:4188 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ioctl$KVM_SET_TSC_KHZ(r2, 0xaea2, 0x1) user_tsc_khz = 0x1 | kvm_set_tsc_khz(struct kvm_vcpu *vcpu, u32 user_tsc_khz) | ioctl$KVM_RUN(r2, 0xae80, 0x0) | ... kvm_guest_time_update(struct kvm_vcpu *v) | if (kvm_caps.has_tsc_control) tgt_tsc_khz = kvm_scale_tsc(tgt_tsc_khz, v->arch.l1_tsc_scaling_ratio); | kvm_scale_tsc(u64 tsc, u64 ratio) | __scale_tsc(u64 ratio, u64 tsc) ratio=122380531, tsc=2299998, N=48 ratio*tsc >> N = 0.999... -> 0 | kvm_get_time_scale In function __scale_tsc, it uses fixed point number to calculate tsc, therefore, a certain degree of precision is lost, the actual tsc value of 0.999... would be 0. In function kvm_get_time_scale tps32=tps64=base_hz=0, would lead second while_loop infinite. when CONFIG_PREEMPT is n, it causes a soft lockup issue. Signed-off-by: Yuntao Liu <liuyuntao12(a)huawei.com> --- arch/x86/kvm/x86.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 1fa5d89f8d27..3e9d6f368eed 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2605,10 +2605,14 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu) * point number (mult + frac * 2^(-N)). * * N equals to kvm_caps.tsc_scaling_ratio_frac_bits. + * + * return 1 if _tsc is 0. */ static inline u64 __scale_tsc(u64 ratio, u64 tsc) { - return mul_u64_u64_shr(tsc, ratio, kvm_caps.tsc_scaling_ratio_frac_bits); + u64 _tsc = mul_u64_u64_shr(tsc, ratio, kvm_caps.tsc_scaling_ratio_frac_bits); + + return !_tsc ? 1 : _tsc; } u64 kvm_scale_tsc(u64 tsc, u64 ratio) -- 2.34.1

2 1

[PATCH OLK-6.6 0/7] arm64: Add support for FEAT_{LS64, LS64_V}
by Yushan Wang 13 May '25

13 May '25

From: Hongye Lin <linhongye(a)h-partners.com> driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/IC76OZ ---------------------------------------------------------------------- Armv8.7 introduces single-copy atomic 64-byte loads and stores instructions and its variants named under FEAT_{LS64, LS64_V}. These features are identified by ID_AA64ISAR1_EL1.LS64 and the use of such instructions in userspace (EL0) can be trapped. In order to support the use of corresponding instructions in userspace: Make ID_AA64ISAR1_EL1.LS64 visbile to userspace Add identifying and enabling in the cpufeature list Expose these support of these features to userspace through HWCAP3 and cpuinfo Mark Brown (2): arm64: Support AT_HWCAP3 binfmt_elf: Wire up AT_HWCAP3 at AT_HWCAP4 Peter Bergner (1): uapi/auxvec: Define AT_HWCAP3 and AT_HWCAP4 aux vector, entries Yicong Yang (4): arm64: Provide basic EL2 setup for FEAT_{LS64, LS64_V} usage at EL0/1 arm64: Add support for FEAT_{LS64, LS64_V} Workaround the issue when compile with CONFIG_FUNCTION_ALIGNMENT_64B KVM: arm64: Enable FEAT_{LS64, LS64_V} in the supported guest Documentation/arch/arm64/booting.rst | 12 +++++ Documentation/arch/arm64/elf_hwcaps.rst | 12 +++-- arch/arm64/Kconfig | 4 ++ arch/arm64/include/asm/cpufeature.h | 3 +- arch/arm64/include/asm/el2_setup.h | 13 ++++++ arch/arm64/include/asm/hwcap.h | 7 ++- arch/arm64/include/uapi/asm/hwcap.h | 6 +++ arch/arm64/kernel/cpufeature.c | 61 +++++++++++++++++++++++++ arch/arm64/kernel/cpuinfo.c | 2 + arch/arm64/kvm/hyp/include/hyp/switch.h | 6 +++ arch/arm64/tools/cpucaps | 4 +- fs/binfmt_elf.c | 6 +++ fs/binfmt_elf_fdpic.c | 6 +++ fs/compat_binfmt_elf.c | 10 ++++ include/uapi/linux/auxvec.h | 2 + 15 files changed, 147 insertions(+), 7 deletions(-) -- 2.33.0

2 8

[PATCH openEuler-1.0-LTS] kvm: x86: fix infinite loop in kvm_guest_time_update when tsc is 0
by Yuntao Liu 13 May '25

13 May '25

hulk inclusion category: bugfix bugzilla: 190614 CVE: NA -------------------------------- Fixes: 35181e86df97 ("KVM: x86: Add a common TSC scaling function") Syzkaller testing detected a soft lockup. watchdog: BUG: soft lockup - CPU#3 stuck for 127s! [syz.1.2088:9817] Modules linked in: CPU: 3 PID: 9817 Comm: syz.1.2088 Tainted: G S 6.6.0+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__sanitizer_cov_trace_const_cmp4+0x8/0x20 kernel/kcov.c:313 Code: bf 03 00 00 00 e9 48 fe ff ff 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 48 8b 0c 24 <89> f2 89 fe bf 05 00 00 00 e9 1a fe ff ff 66 2e 0f 1f 84 00 00 00 RSP: 0018:ffff888016d8fad8 EFLAGS: 00000206 RAX: 0000000000080000 RBX: ffff88810e242540 RCX: ffffffff901150d6 RDX: 0000000000080000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff888016d8fb50 R08: 0000000000000001 R09: ffffed1021c484af R10: 0000000000000000 R11: 0000000000000277 R12: 0000000000000000 R13: fffffed357281918 R14: 0000000000000000 R15: 0000000000000001 FS: 00007f2a8f6ea6c0(0000) GS:ffff888119780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000012c56c0 CR3: 000000000dce8001 CR4: 0000000000772ee0 DR0: 0000000000000000 DR1: 0000000000d3eb1c DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> kvm_get_time_scale arch/x86/kvm/x86.c:2458 [inline] kvm_guest_time_update+0x926/0xb00 arch/x86/kvm/x86.c:3268 vcpu_enter_guest.constprop.0+0x1e70/0x3cf0 arch/x86/kvm/x86.c:10678 vcpu_run+0x129/0x8d0 arch/x86/kvm/x86.c:11126 kvm_arch_vcpu_ioctl_run+0x37a/0x13d0 arch/x86/kvm/x86.c:11352 kvm_vcpu_ioctl+0x56b/0xe60 virt/kvm/kvm_main.c:4188 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ioctl$KVM_SET_TSC_KHZ(r2, 0xaea2, 0x1) user_tsc_khz = 0x1 | kvm_set_tsc_khz(struct kvm_vcpu *vcpu, u32 user_tsc_khz) | ioctl$KVM_RUN(r2, 0xae80, 0x0) | ... kvm_guest_time_update(struct kvm_vcpu *v) | if (kvm_caps.has_tsc_control) tgt_tsc_khz = kvm_scale_tsc(tgt_tsc_khz, v->arch.l1_tsc_scaling_ratio); | kvm_scale_tsc(u64 tsc, u64 ratio) | __scale_tsc(u64 ratio, u64 tsc) ratio=122380531, tsc=2299998, N=48 ratio*tsc >> N = 0.999... -> 0 | kvm_get_time_scale In function __scale_tsc, it uses fixed point number to calculate tsc, therefore, a certain degree of precision is lost, the actual tsc value of 0.999... would be 0. In function kvm_get_time_scale tps32=tps64=base_hz=0, would lead second while_loop infinite. when CONFIG_PREEMPT is n, it causes a soft lockup issue. Signed-off-by: Yuntao Liu <liuyuntao12(a)huawei.com> --- arch/x86/kvm/x86.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 6afffdcc656e..83d215d43eb3 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -1673,10 +1673,14 @@ static void update_ia32_tsc_adjust_msr(struct kvm_vcpu *vcpu, s64 offset) * point number (mult + frac * 2^(-N)). * * N equals to kvm_tsc_scaling_ratio_frac_bits. + * + * return 1 if _tsc is 0. */ static inline u64 __scale_tsc(u64 ratio, u64 tsc) { - return mul_u64_u64_shr(tsc, ratio, kvm_tsc_scaling_ratio_frac_bits); + u64 _tsc = mul_u64_u64_shr(tsc, ratio, kvm_tsc_scaling_ratio_frac_bits); + + return !_tsc ? 1 : _tsc; } u64 kvm_scale_tsc(struct kvm_vcpu *vcpu, u64 tsc) -- 2.34.1

2 1

[PATCH OLK-5.10] kvm: x86: fix infinite loop in kvm_guest_time_update when tsc is 0
by Yuntao Liu 13 May '25

13 May '25

hulk inclusion category: bugfix bugzilla: 190614 CVE: NA -------------------------------- Fixes: 35181e86df97 ("KVM: x86: Add a common TSC scaling function") Syzkaller testing detected a soft lockup. watchdog: BUG: soft lockup - CPU#3 stuck for 127s! [syz.1.2088:9817] Modules linked in: CPU: 3 PID: 9817 Comm: syz.1.2088 Tainted: G S 6.6.0+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__sanitizer_cov_trace_const_cmp4+0x8/0x20 kernel/kcov.c:313 Code: bf 03 00 00 00 e9 48 fe ff ff 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 48 8b 0c 24 <89> f2 89 fe bf 05 00 00 00 e9 1a fe ff ff 66 2e 0f 1f 84 00 00 00 RSP: 0018:ffff888016d8fad8 EFLAGS: 00000206 RAX: 0000000000080000 RBX: ffff88810e242540 RCX: ffffffff901150d6 RDX: 0000000000080000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff888016d8fb50 R08: 0000000000000001 R09: ffffed1021c484af R10: 0000000000000000 R11: 0000000000000277 R12: 0000000000000000 R13: fffffed357281918 R14: 0000000000000000 R15: 0000000000000001 FS: 00007f2a8f6ea6c0(0000) GS:ffff888119780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000012c56c0 CR3: 000000000dce8001 CR4: 0000000000772ee0 DR0: 0000000000000000 DR1: 0000000000d3eb1c DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> kvm_get_time_scale arch/x86/kvm/x86.c:2458 [inline] kvm_guest_time_update+0x926/0xb00 arch/x86/kvm/x86.c:3268 vcpu_enter_guest.constprop.0+0x1e70/0x3cf0 arch/x86/kvm/x86.c:10678 vcpu_run+0x129/0x8d0 arch/x86/kvm/x86.c:11126 kvm_arch_vcpu_ioctl_run+0x37a/0x13d0 arch/x86/kvm/x86.c:11352 kvm_vcpu_ioctl+0x56b/0xe60 virt/kvm/kvm_main.c:4188 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ioctl$KVM_SET_TSC_KHZ(r2, 0xaea2, 0x1) user_tsc_khz = 0x1 | kvm_set_tsc_khz(struct kvm_vcpu *vcpu, u32 user_tsc_khz) | ioctl$KVM_RUN(r2, 0xae80, 0x0) | ... kvm_guest_time_update(struct kvm_vcpu *v) | if (kvm_caps.has_tsc_control) tgt_tsc_khz = kvm_scale_tsc(tgt_tsc_khz, v->arch.l1_tsc_scaling_ratio); | kvm_scale_tsc(u64 tsc, u64 ratio) | __scale_tsc(u64 ratio, u64 tsc) ratio=122380531, tsc=2299998, N=48 ratio*tsc >> N = 0.999... -> 0 | kvm_get_time_scale In function __scale_tsc, it uses fixed point number to calculate tsc, therefore, a certain degree of precision is lost, the actual tsc value of 0.999... would be 0. In function kvm_get_time_scale tps32=tps64=base_hz=0, would lead second while_loop infinite. when CONFIG_PREEMPT is n, it causes a soft lockup issue. Signed-off-by: Yuntao Liu <liuyuntao12(a)huawei.com> --- arch/x86/kvm/x86.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index d2d206ff6462..dec2d3baf202 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2428,10 +2428,14 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu) * point number (mult + frac * 2^(-N)). * * N equals to kvm_tsc_scaling_ratio_frac_bits. + * + * return 1 if _tsc is 0. */ static inline u64 __scale_tsc(u64 ratio, u64 tsc) { - return mul_u64_u64_shr(tsc, ratio, kvm_tsc_scaling_ratio_frac_bits); + u64 _tsc = mul_u64_u64_shr(tsc, ratio, kvm_tsc_scaling_ratio_frac_bits); + + return !_tsc ? 1 : _tsc; } u64 kvm_scale_tsc(struct kvm_vcpu *vcpu, u64 tsc) -- 2.34.1

2 1

[PATCH OLK-6.6] kvm: x86: fix infinite loop in kvm_guest_time_update when tsc is 0
by Yuntao Liu 13 May '25

13 May '25

hulk inclusion category: bugfix bugzilla: 190614 CVE: NA -------------------------------- Fixes: 35181e86df97 ("KVM: x86: Add a common TSC scaling function") Syzkaller testing detected a soft lockup. watchdog: BUG: soft lockup - CPU#3 stuck for 127s! [syz.1.2088:9817] Modules linked in: CPU: 3 PID: 9817 Comm: syz.1.2088 Tainted: G S 6.6.0+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__sanitizer_cov_trace_const_cmp4+0x8/0x20 kernel/kcov.c:313 Code: bf 03 00 00 00 e9 48 fe ff ff 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 48 8b 0c 24 <89> f2 89 fe bf 05 00 00 00 e9 1a fe ff ff 66 2e 0f 1f 84 00 00 00 RSP: 0018:ffff888016d8fad8 EFLAGS: 00000206 RAX: 0000000000080000 RBX: ffff88810e242540 RCX: ffffffff901150d6 RDX: 0000000000080000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff888016d8fb50 R08: 0000000000000001 R09: ffffed1021c484af R10: 0000000000000000 R11: 0000000000000277 R12: 0000000000000000 R13: fffffed357281918 R14: 0000000000000000 R15: 0000000000000001 FS: 00007f2a8f6ea6c0(0000) GS:ffff888119780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000012c56c0 CR3: 000000000dce8001 CR4: 0000000000772ee0 DR0: 0000000000000000 DR1: 0000000000d3eb1c DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> kvm_get_time_scale arch/x86/kvm/x86.c:2458 [inline] kvm_guest_time_update+0x926/0xb00 arch/x86/kvm/x86.c:3268 vcpu_enter_guest.constprop.0+0x1e70/0x3cf0 arch/x86/kvm/x86.c:10678 vcpu_run+0x129/0x8d0 arch/x86/kvm/x86.c:11126 kvm_arch_vcpu_ioctl_run+0x37a/0x13d0 arch/x86/kvm/x86.c:11352 kvm_vcpu_ioctl+0x56b/0xe60 virt/kvm/kvm_main.c:4188 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ioctl$KVM_SET_TSC_KHZ(r2, 0xaea2, 0x1) user_tsc_khz = 0x1 | kvm_set_tsc_khz(struct kvm_vcpu *vcpu, u32 user_tsc_khz) | ioctl$KVM_RUN(r2, 0xae80, 0x0) | ... kvm_guest_time_update(struct kvm_vcpu *v) | if (kvm_caps.has_tsc_control) tgt_tsc_khz = kvm_scale_tsc(tgt_tsc_khz, v->arch.l1_tsc_scaling_ratio); | kvm_scale_tsc(u64 tsc, u64 ratio) | __scale_tsc(u64 ratio, u64 tsc) ratio=122380531, tsc=2299998, N=48 ratio*tsc >> N = 0.999... -> 0 | kvm_get_time_scale In function __scale_tsc, it uses fixed point number to calculate tsc, therefore, a certain degree of precision is lost, the actual tsc value of 0.999... would be 0. In function kvm_get_time_scale tps32=tps64=base_hz=0, would lead second while_loop infinite. when CONFIG_PREEMPT is n, it causes a soft lockup issue. Signed-off-by: Yuntao Liu <liuyuntao12(a)huawei.com> --- arch/x86/kvm/x86.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 1fa5d89f8d27..3e9d6f368eed 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2605,10 +2605,14 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu) * point number (mult + frac * 2^(-N)). * * N equals to kvm_caps.tsc_scaling_ratio_frac_bits. + * + * return 1 if _tsc is 0. */ static inline u64 __scale_tsc(u64 ratio, u64 tsc) { - return mul_u64_u64_shr(tsc, ratio, kvm_caps.tsc_scaling_ratio_frac_bits); + u64 _tsc = mul_u64_u64_shr(tsc, ratio, kvm_caps.tsc_scaling_ratio_frac_bits); + + return !_tsc ? 1 : _tsc; } u64 kvm_scale_tsc(u64 tsc, u64 ratio) -- 2.34.1

2 1

[PATCH OLK-6.6] kvm: x86: fix infinite loop in kvm_guest_time_update when tsc is 0
by Yuntao Liu 13 May '25

13 May '25

Offering: HULK hulk inclusion category: bugfix bugzilla: 190614 CVE: NA -------------------------------- Fixes: 35181e86df97 ("KVM: x86: Add a common TSC scaling function") Syzkaller testing detected a soft lockup. watchdog: BUG: soft lockup - CPU#3 stuck for 127s! [syz.1.2088:9817] Modules linked in: CPU: 3 PID: 9817 Comm: syz.1.2088 Tainted: G S 6.6.0+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__sanitizer_cov_trace_const_cmp4+0x8/0x20 kernel/kcov.c:313 Code: bf 03 00 00 00 e9 48 fe ff ff 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 48 8b 0c 24 <89> f2 89 fe bf 05 00 00 00 e9 1a fe ff ff 66 2e 0f 1f 84 00 00 00 RSP: 0018:ffff888016d8fad8 EFLAGS: 00000206 RAX: 0000000000080000 RBX: ffff88810e242540 RCX: ffffffff901150d6 RDX: 0000000000080000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff888016d8fb50 R08: 0000000000000001 R09: ffffed1021c484af R10: 0000000000000000 R11: 0000000000000277 R12: 0000000000000000 R13: fffffed357281918 R14: 0000000000000000 R15: 0000000000000001 FS: 00007f2a8f6ea6c0(0000) GS:ffff888119780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000012c56c0 CR3: 000000000dce8001 CR4: 0000000000772ee0 DR0: 0000000000000000 DR1: 0000000000d3eb1c DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> kvm_get_time_scale arch/x86/kvm/x86.c:2458 [inline] kvm_guest_time_update+0x926/0xb00 arch/x86/kvm/x86.c:3268 vcpu_enter_guest.constprop.0+0x1e70/0x3cf0 arch/x86/kvm/x86.c:10678 vcpu_run+0x129/0x8d0 arch/x86/kvm/x86.c:11126 kvm_arch_vcpu_ioctl_run+0x37a/0x13d0 arch/x86/kvm/x86.c:11352 kvm_vcpu_ioctl+0x56b/0xe60 virt/kvm/kvm_main.c:4188 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ioctl$KVM_SET_TSC_KHZ(r2, 0xaea2, 0x1) user_tsc_khz = 0x1 | kvm_set_tsc_khz(struct kvm_vcpu *vcpu, u32 user_tsc_khz) | ioctl$KVM_RUN(r2, 0xae80, 0x0) | ... kvm_guest_time_update(struct kvm_vcpu *v) | if (kvm_caps.has_tsc_control) tgt_tsc_khz = kvm_scale_tsc(tgt_tsc_khz, v->arch.l1_tsc_scaling_ratio); | kvm_scale_tsc(u64 tsc, u64 ratio) | __scale_tsc(u64 ratio, u64 tsc) ratio=122380531, tsc=2299998, N=48 ratio*tsc >> N = 0.999... -> 0 | kvm_get_time_scale In function __scale_tsc, it uses fixed point number to calculate tsc, therefore, a certain degree of precision is lost, the actual tsc value of 0.999... would be 0. In function kvm_get_time_scale tps32=tps64=base_hz=0, would lead second while_loop infinite. when CONFIG_PREEMPT is n, it causes a soft lockup issue. Signed-off-by: Yuntao Liu <liuyuntao12(a)huawei.com> --- arch/x86/kvm/x86.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 1fa5d89f8d27..3e9d6f368eed 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2605,10 +2605,14 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu) * point number (mult + frac * 2^(-N)). * * N equals to kvm_caps.tsc_scaling_ratio_frac_bits. + * + * return 1 if _tsc is 0. */ static inline u64 __scale_tsc(u64 ratio, u64 tsc) { - return mul_u64_u64_shr(tsc, ratio, kvm_caps.tsc_scaling_ratio_frac_bits); + u64 _tsc = mul_u64_u64_shr(tsc, ratio, kvm_caps.tsc_scaling_ratio_frac_bits); + + return !_tsc ? 1 : _tsc; } u64 kvm_scale_tsc(u64 tsc, u64 ratio) -- 2.34.1

2 1

[PATCH OLK-6.6] kvm: x86: fix infinite loop in kvm_guest_time_update when tsc is 0
by Yuntao Liu 13 May '25

13 May '25

Offering: HULK hulk inclusion category: bugfix bugzilla: 190614 CVE: NA -------------------------------- Fixes: 35181e86df97 ("KVM: x86: Add a common TSC scaling function") Syzkaller testing detected a soft lockup. watchdog: BUG: soft lockup - CPU#3 stuck for 127s! [syz.1.2088:9817] Modules linked in: CPU: 3 PID: 9817 Comm: syz.1.2088 Tainted: G S 6.6.0+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__sanitizer_cov_trace_const_cmp4+0x8/0x20 kernel/kcov.c:313 Code: bf 03 00 00 00 e9 48 fe ff ff 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 48 8b 0c 24 <89> f2 89 fe bf 05 00 00 00 e9 1a fe ff ff 66 2e 0f 1f 84 00 00 00 RSP: 0018:ffff888016d8fad8 EFLAGS: 00000206 RAX: 0000000000080000 RBX: ffff88810e242540 RCX: ffffffff901150d6 RDX: 0000000000080000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff888016d8fb50 R08: 0000000000000001 R09: ffffed1021c484af R10: 0000000000000000 R11: 0000000000000277 R12: 0000000000000000 R13: fffffed357281918 R14: 0000000000000000 R15: 0000000000000001 FS: 00007f2a8f6ea6c0(0000) GS:ffff888119780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000012c56c0 CR3: 000000000dce8001 CR4: 0000000000772ee0 DR0: 0000000000000000 DR1: 0000000000d3eb1c DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> kvm_get_time_scale arch/x86/kvm/x86.c:2458 [inline] kvm_guest_time_update+0x926/0xb00 arch/x86/kvm/x86.c:3268 vcpu_enter_guest.constprop.0+0x1e70/0x3cf0 arch/x86/kvm/x86.c:10678 vcpu_run+0x129/0x8d0 arch/x86/kvm/x86.c:11126 kvm_arch_vcpu_ioctl_run+0x37a/0x13d0 arch/x86/kvm/x86.c:11352 kvm_vcpu_ioctl+0x56b/0xe60 virt/kvm/kvm_main.c:4188 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ioctl$KVM_SET_TSC_KHZ(r2, 0xaea2, 0x1) user_tsc_khz = 0x1 | kvm_set_tsc_khz(struct kvm_vcpu *vcpu, u32 user_tsc_khz) | ioctl$KVM_RUN(r2, 0xae80, 0x0) | ... kvm_guest_time_update(struct kvm_vcpu *v) | if (kvm_caps.has_tsc_control) tgt_tsc_khz = kvm_scale_tsc(tgt_tsc_khz, v->arch.l1_tsc_scaling_ratio); | kvm_scale_tsc(u64 tsc, u64 ratio) | __scale_tsc(u64 ratio, u64 tsc) ratio=122380531, tsc=2299998, N=48 ratio*tsc >> N = 0.999... -> 0 | kvm_get_time_scale In function __scale_tsc, it uses fixed point number to calculate tsc, therefore, a certain degree of precision is lost, the actual tsc value of 0.999... would be 0. In function kvm_get_time_scale tps32=tps64=base_hz=0, would lead second while_loop infinite. when CONFIG_PREEMPT is n, it causes a soft lockup issue. Signed-off-by: Yuntao Liu <liuyuntao12(a)huawei.com> --- arch/x86/kvm/x86.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 1fa5d89f8d27..57a12f2a4642 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2605,10 +2605,14 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu) * point number (mult + frac * 2^(-N)). * * N equals to kvm_caps.tsc_scaling_ratio_frac_bits. + * + * return 1 if _tsc is 0. */ static inline u64 __scale_tsc(u64 ratio, u64 tsc) { - return mul_u64_u64_shr(tsc, ratio, kvm_caps.tsc_scaling_ratio_frac_bits); + u64 _tsc = mul_u64_u64_shr(tsc, ratio, kvm_caps.tsc_scaling_ratio_frac_bits); + + return !_tsc ? 1 : _tsc; } u64 kvm_scale_tsc(u64 tsc, u64 ratio) -- 2.34.1

2 1

[PATCH OLK-5.10] kvm: x86: fix infinite loop in kvm_guest_time_update when tsc is 0
by Yuntao Liu 13 May '25

13 May '25

Offering: HULK hulk inclusion category: bugfix bugzilla: 190614 CVE: NA -------------------------------- Fixes: 35181e86df97 ("KVM: x86: Add a common TSC scaling function") Syzkaller testing detected a soft lockup. watchdog: BUG: soft lockup - CPU#3 stuck for 127s! [syz.1.2088:9817] Modules linked in: CPU: 3 PID: 9817 Comm: syz.1.2088 Tainted: G S 6.6.0+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__sanitizer_cov_trace_const_cmp4+0x8/0x20 kernel/kcov.c:313 Code: bf 03 00 00 00 e9 48 fe ff ff 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 48 8b 0c 24 <89> f2 89 fe bf 05 00 00 00 e9 1a fe ff ff 66 2e 0f 1f 84 00 00 00 RSP: 0018:ffff888016d8fad8 EFLAGS: 00000206 RAX: 0000000000080000 RBX: ffff88810e242540 RCX: ffffffff901150d6 RDX: 0000000000080000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff888016d8fb50 R08: 0000000000000001 R09: ffffed1021c484af R10: 0000000000000000 R11: 0000000000000277 R12: 0000000000000000 R13: fffffed357281918 R14: 0000000000000000 R15: 0000000000000001 FS: 00007f2a8f6ea6c0(0000) GS:ffff888119780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000012c56c0 CR3: 000000000dce8001 CR4: 0000000000772ee0 DR0: 0000000000000000 DR1: 0000000000d3eb1c DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> kvm_get_time_scale arch/x86/kvm/x86.c:2458 [inline] kvm_guest_time_update+0x926/0xb00 arch/x86/kvm/x86.c:3268 vcpu_enter_guest.constprop.0+0x1e70/0x3cf0 arch/x86/kvm/x86.c:10678 vcpu_run+0x129/0x8d0 arch/x86/kvm/x86.c:11126 kvm_arch_vcpu_ioctl_run+0x37a/0x13d0 arch/x86/kvm/x86.c:11352 kvm_vcpu_ioctl+0x56b/0xe60 virt/kvm/kvm_main.c:4188 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ioctl$KVM_SET_TSC_KHZ(r2, 0xaea2, 0x1) user_tsc_khz = 0x1 | kvm_set_tsc_khz(struct kvm_vcpu *vcpu, u32 user_tsc_khz) | ioctl$KVM_RUN(r2, 0xae80, 0x0) | ... kvm_guest_time_update(struct kvm_vcpu *v) | if (kvm_caps.has_tsc_control) tgt_tsc_khz = kvm_scale_tsc(tgt_tsc_khz, v->arch.l1_tsc_scaling_ratio); | kvm_scale_tsc(u64 tsc, u64 ratio) | __scale_tsc(u64 ratio, u64 tsc) ratio=122380531, tsc=2299998, N=48 ratio*tsc >> N = 0.999... -> 0 | kvm_get_time_scale In function __scale_tsc, it uses fixed point number to calculate tsc, therefore, a certain degree of precision is lost, the actual tsc value of 0.999... would be 0. In function kvm_get_time_scale tps32=tps64=base_hz=0, would lead second while_loop infinite. when CONFIG_PREEMPT is n, it causes a soft lockup issue. Signed-off-by: Yuntao Liu <liuyuntao12(a)huawei.com> --- arch/x86/kvm/x86.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index d2d206ff6462..dec2d3baf202 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2428,10 +2428,14 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu) * point number (mult + frac * 2^(-N)). * * N equals to kvm_tsc_scaling_ratio_frac_bits. + * + * return 1 if _tsc is 0. */ static inline u64 __scale_tsc(u64 ratio, u64 tsc) { - return mul_u64_u64_shr(tsc, ratio, kvm_tsc_scaling_ratio_frac_bits); + u64 _tsc = mul_u64_u64_shr(tsc, ratio, kvm_tsc_scaling_ratio_frac_bits); + + return !_tsc ? 1 : _tsc; } u64 kvm_scale_tsc(struct kvm_vcpu *vcpu, u64 tsc) -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] kvm: x86: fix infinite loop in kvm_guest_time_update when tsc is 0
by Yuntao Liu 13 May '25

13 May '25

Offering: HULK hulk inclusion category: bugfix bugzilla: 190614 CVE: NA -------------------------------- Fixes: 35181e86df97 ("KVM: x86: Add a common TSC scaling function") Syzkaller testing detected a soft lockup. watchdog: BUG: soft lockup - CPU#3 stuck for 127s! [syz.1.2088:9817] Modules linked in: CPU: 3 PID: 9817 Comm: syz.1.2088 Tainted: G S 6.6.0+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__sanitizer_cov_trace_const_cmp4+0x8/0x20 kernel/kcov.c:313 Code: bf 03 00 00 00 e9 48 fe ff ff 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 48 8b 0c 24 <89> f2 89 fe bf 05 00 00 00 e9 1a fe ff ff 66 2e 0f 1f 84 00 00 00 RSP: 0018:ffff888016d8fad8 EFLAGS: 00000206 RAX: 0000000000080000 RBX: ffff88810e242540 RCX: ffffffff901150d6 RDX: 0000000000080000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff888016d8fb50 R08: 0000000000000001 R09: ffffed1021c484af R10: 0000000000000000 R11: 0000000000000277 R12: 0000000000000000 R13: fffffed357281918 R14: 0000000000000000 R15: 0000000000000001 FS: 00007f2a8f6ea6c0(0000) GS:ffff888119780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000012c56c0 CR3: 000000000dce8001 CR4: 0000000000772ee0 DR0: 0000000000000000 DR1: 0000000000d3eb1c DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> kvm_get_time_scale arch/x86/kvm/x86.c:2458 [inline] kvm_guest_time_update+0x926/0xb00 arch/x86/kvm/x86.c:3268 vcpu_enter_guest.constprop.0+0x1e70/0x3cf0 arch/x86/kvm/x86.c:10678 vcpu_run+0x129/0x8d0 arch/x86/kvm/x86.c:11126 kvm_arch_vcpu_ioctl_run+0x37a/0x13d0 arch/x86/kvm/x86.c:11352 kvm_vcpu_ioctl+0x56b/0xe60 virt/kvm/kvm_main.c:4188 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ioctl$KVM_SET_TSC_KHZ(r2, 0xaea2, 0x1) user_tsc_khz = 0x1 | kvm_set_tsc_khz(struct kvm_vcpu *vcpu, u32 user_tsc_khz) | ioctl$KVM_RUN(r2, 0xae80, 0x0) | ... kvm_guest_time_update(struct kvm_vcpu *v) | if (kvm_caps.has_tsc_control) tgt_tsc_khz = kvm_scale_tsc(tgt_tsc_khz, v->arch.l1_tsc_scaling_ratio); | kvm_scale_tsc(u64 tsc, u64 ratio) | __scale_tsc(u64 ratio, u64 tsc) ratio=122380531, tsc=2299998, N=48 ratio*tsc >> N = 0.999... -> 0 | kvm_get_time_scale In function __scale_tsc, it uses fixed point number to calculate tsc, therefore, a certain degree of precision is lost, the actual tsc value of 0.999... would be 0. In function kvm_get_time_scale tps32=tps64=base_hz=0, would lead second while_loop infinite. when CONFIG_PREEMPT is n, it causes a soft lockup issue. Signed-off-by: Yuntao Liu <liuyuntao12(a)huawei.com> --- arch/x86/kvm/x86.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 6afffdcc656e..83d215d43eb3 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -1673,10 +1673,14 @@ static void update_ia32_tsc_adjust_msr(struct kvm_vcpu *vcpu, s64 offset) * point number (mult + frac * 2^(-N)). * * N equals to kvm_tsc_scaling_ratio_frac_bits. + * + * return 1 if _tsc is 0. */ static inline u64 __scale_tsc(u64 ratio, u64 tsc) { - return mul_u64_u64_shr(tsc, ratio, kvm_tsc_scaling_ratio_frac_bits); + u64 _tsc = mul_u64_u64_shr(tsc, ratio, kvm_tsc_scaling_ratio_frac_bits); + + return !_tsc ? 1 : _tsc; } u64 kvm_scale_tsc(struct kvm_vcpu *vcpu, u64 tsc) -- 2.34.1

2 1