[syzbot ci] Re: KVM: x86: Unify L1TF flushing under per-CPU variable

[syzbot ci]

syzbot ci has tested the following series

[v1] KVM: x86: Unify L1TF flushing under per-CPU variable
https://lore.kernel.org/all/20251013-b4-l1tf-per...@google.com
* [PATCH] KVM: x86: Unify L1TF flushing under per-CPU variable

and found the following issue:
BUG: using __this_cpu_write() in preemptible code in x86_emulate_instruction

Full report is available here:
https://ci.syzbot.org/series/c0a39c51-4121-4883-a21f-4277f63b3118

***

BUG: using __this_cpu_write() in preemptible code in x86_emulate_instruction

tree: kvm-next
URL: https://kernel.googlesource.com/pub/scm/virt/kvm/kvm/
base: 6b36119b94d0b2bb8cea9d512017efafd461d6ac
arch: amd64
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
config: https://ci.syzbot.org/builds/a964957a-128c-43dd-b6df-7758575a9993/config
C repro: https://ci.syzbot.org/findings/c0c645e8-abe2-437f-aa29-1adf339cb732/c_repro
syz repro: https://ci.syzbot.org/findings/c0c645e8-abe2-437f-aa29-1adf339cb732/syz_repro

BUG: using __this_cpu_write() in preemptible [00000000] code: syz.0.17/5962
caller is kvm_set_cpu_l1tf_flush_l1d arch/x86/include/asm/kvm_host.h:2486 [inline]
caller is x86_emulate_instruction+0x1a4/0x1f70 arch/x86/kvm/x86.c:9405
CPU: 1 UID: 0 PID: 5962 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
check_preemption_disabled+0x10a/0x120 lib/smp_processor_id.c:47
kvm_set_cpu_l1tf_flush_l1d arch/x86/include/asm/kvm_host.h:2486 [inline]
x86_emulate_instruction+0x1a4/0x1f70 arch/x86/kvm/x86.c:9405
kvm_mmu_page_fault+0x91a/0xb70 arch/x86/kvm/mmu/mmu.c:6385
__vmx_handle_exit arch/x86/kvm/vmx/vmx.c:6624 [inline]
vmx_handle_exit+0x10a4/0x18c0 arch/x86/kvm/vmx/vmx.c:6641
vcpu_enter_guest arch/x86/kvm/x86.c:11461 [inline]
vcpu_run+0x4359/0x6fc0 arch/x86/kvm/x86.c:11619
kvm_arch_vcpu_ioctl_run+0xfc9/0x1940 arch/x86/kvm/x86.c:11958
kvm_vcpu_ioctl+0x95c/0xe90 virt/kvm/kvm_main.c:4476
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:598 [inline]
__se_sys_ioctl+0xf9/0x170 fs/ioctl.c:584
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f0f9698eec9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff7c8600c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f0f96be5fa0 RCX: 00007f0f9698eec9
RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005
RBP: 00007f0f96a11f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f0f96be5fa0 R14: 00007f0f96be5fa0 R15: 0000000000000003
</TASK>


***

If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
Tested-by: syz...@syzkaller.appspotmail.com

---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzk...@googlegroups.com.

[Brendan Jackman]

On Tue Oct 14, 2025 at 6:13 AM UTC, syzbot ci wrote:
> BUG: using __this_cpu_write() in preemptible code in x86_emulate_instruction

Ah. And now I realise I never booted my debug config on an actual
Skylake host, I'd better do that, presumably running the KVM selftests
with DEBUG_PREEMPT etc would have been enough to catch this earlier.

Anyway, I guest we just want to use vcpu->arch.last_vmentry_cpu instead
of smp_processor_id()?

[Brendan Jackman]

Just went to code it up and changed my mind about this. If the vCPU is
being migrated, it doesn't really matter which CPU stuff like
x86_emulate_instruction() sets the bit on since it's vcpu_load()'s job to
make sure it's set on the CPU that actually needs it. So I think instead
we just want raw_cpu_write() here, then there's no pointless remote
updates. The bit might get set on a CPU that doesn't end up needing it
for the current vCPU, but it was gonna get the bit set before it ran the
next vCPU anyway.