## Host environment - Operating system: Ubuntu 26.04.1 LTS - OS/kernel version: Linux 7.0.0-34-generic x86_64 - Architecture: x86_64 (TCG, no KVM) - QEMU flavor: qemu-system-x86_64, also qemu-system-i386 - QEMU version: 11.1.50 (v11.1.0-1709-g7074591d79), built from master, and 10.2.1 (Ubuntu) - QEMU command line: ``` ./qemu-system-x86_64 -M q35 -accel tcg,thread=multi -cpu qemu64 -smp 4 -m 1536 \ -display none -monitor none -nic none -serial stdio -no-reboot \ -kernel bzImage -initrd initramfs.cpio.gz \ -append "console=ttyS0 rdinit=/init oops=panic panic=-1" ``` ## Emulated/Virtualized environment - Operating system: Linux, x86_64_defconfig plus CONFIG_FUNCTION_TRACER=y and CONFIG_FUNCTION_GRAPH_TRACER=y, busybox initramfs - OS/kernel version: 7.3.0-rc5 (72d3fcf802c4), unmodified - Architecture: x86_64, also seen with an i386 kernel under qemu-system-i386 ## Description of problem Disclosure: AI-assisted tooling helped prepare this report. I ran and verified the tests below. A Linux guest that switches the ftrace tracer between function_graph and nop under a light load dies within the first dozen switches: ``` Oops: int3: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 101 Comm: busybox Not tainted 7.3.0-rc5 #1 PREEMPT(lazy) RIP: 0010:do_wp_page+0x1/0xd10 ``` The site varies, it is always a call that ftrace patches. With thread=single, under KVM and under Bochs the same loop completed (100, 200 and 10 switches, lockdep build of this kernel). text_poke_bp writes an INT3 over the first byte, then the other four bytes, then the first byte again, with a serializing IPI to every CPU after each step. The int3 handler resolves the temporary INT3s from the batch. The oops is a vCPU executing one after the last step and its IPI have completed. The cause may be in accel/tcg/cputlb.c. notdirty_write() invalidates the TBs that overlap a store under the page lock and returns, and the store lands afterwards without the lock. tb_gen_code() on another vCPU holds the lock from the code read to tb_link_page(). A vCPU that translates between the invalidation and the store would read the old byte and link a TB that survives the store. The guest's IPI does not invalidate TBs. An instrumented build agrees: memory holds the new opcode when the stale INT3 runs. The kernel side was discussed on LKML in 2025 with the same signature (https://lore.kernel.org/r/20250611113001.GC2273038@noisy.programming.kicks-ass.net). The fix from that thread, 2aebf5ee43bf, is in 7.3-rc5 and does not cover this. ## Steps to reproduce 1. Build v7.3-rc5 with x86_64_defconfig plus CONFIG_FUNCTION_TRACER=y and CONFIG_FUNCTION_GRAPH_TRACER=y. 2. Build an initramfs from a static busybox as /bin/busybox and this init: ```sh #!/bin/busybox sh BB=/bin/busybox $BB mkdir -p /proc /sys /dev $BB mount -t proc proc /proc $BB mount -t sysfs sysfs /sys $BB mount -t devtmpfs devtmpfs /dev $BB mount -t tracefs tracefs /sys/kernel/tracing $BB ifconfig lo 127.0.0.1 up T=/sys/kernel/tracing ($BB sh -c 'while :; do '$BB' usleep 1000; done') & ($BB sh -c 'while :; do '$BB' true; done') & ($BB sh -c 'while :; do '$BB' ping -q -c 256 -i 0.01 127.0.0.1 >/dev/null 2>&1; done') & $BB echo 0 > $T/tracing_on i=0 while test $i -lt 100; do $BB echo function_graph > $T/current_tracer $BB usleep 100000 $BB echo nop > $T/current_tracer $BB usleep 100000 i=$((i+1)) $BB echo "round $i" done $BB echo "DONE: 100 rounds" $BB poweroff -f ``` 3. Boot with the command line above. The oops comes within the first rounds, 100 to 330 s after boot (rounds 5, 13 and 7 in three runs). ## Additional information First stale event of an instrumented run, host monotonic time. The store restores the first byte at guest ram 0x10a9c20, 0xe8 is the CALL opcode: ``` QEMU-NOTDIRTY t=...599806 cpu=1 ram=0x10a9c20 size=1 QEMU-TRANSLATE-INT3 t=...599845 cpu=3 pc=0xffffffff810a9c20 +39 us, TB starts with 0xcc QEMU-STALE-INT3 t=...599861 cpu=3 pc=0xffffffff810a9c20 byte=0xe8 +55 us QEMU-STALE-INT3 t=...599862 cpu=1 pc=0xffffffff810a9c20 byte=0xe8 the writer itself ``` The prints are an fprintf in notdirty_write(), one in the translator when a TB starts with 0xcc, and one in the INT3 path reading the byte back with cpu_memory_rw_debug().