Hi all, I am not really sure whose bug this is, as it only appears when three seemingly independent patch series are applied together, so I have added the patch authors and their committers (along with the tracing maintainers) to this thread. Feel free to expand or reduce that list as necessary. Our continuous integration has noticed a crash when booting ppc64_guest_defconfig in QEMU on the past few -next versions. https://github.com/ClangBuiltLinux/continuous-integration2/actions/runs/23311154492/job/67811527112 This does not appear to be clang related, as it can be reproduced with GCC 15.2.0 as well. Through multiple bisects, I was able to land on applying: mm: improve RSS counter approximation accuracy for proc interfaces [1] vdso/datastore: Allocate data pages dynamically [2] kho: fix deferred init of kho scratch [3] and their dependent changes on top of 7.0-rc4 is enough to reproduce this (at least on two of my machines with the same commands). I have attached the diff from the result of the following 'git apply' commands below, done in a linux-next checkout. $ git checkout v7.0-rc4 HEAD is now at f338e7738378 Linux 7.0-rc4 # [1] $ git diff 60ddf3eed4999bae440d1cf9e5868ccb3f308b64^..087dd6d2cc12c82945ab859194c32e8e977daae3 | git apply -3v ... # [2] # Fix trivial conflict in init/main.c around headers $ git diff dc432ab7130bb39f5a351281a02d4bc61e85a14a^..05988dba11791ccbb458254484826b32f17f4ad2 | git apply -3v ... # [3] # Fix conflict in kernel/liveupdate/kexec_handover.c due to lack of kho_mem_retrieve(), just add pfn_is_kho_scratch() $ git show 4a78467ffb537463486968232daef1e8a2f105e3 | git apply -3v ... $ make -skj"$(nproc)" ARCH=powerpc CROSS_COMPILE=powerpc64-linux- mrproper ppc64_guest_defconfig vmlinux $ curl -LSs https://github.com/ClangBuiltLinux/boot-utils/releases/download/20241120-044434/ppc64-rootfs.cpio.zst | zstd -d >rootfs.cpio $ qemu-system-ppc64 \ -display none \ -nodefaults \ -cpu power8 \ -machine pseries \ -vga none \ -kernel vmlinux \ -initrd rootfs.cpio \ -m 1G \ -serial mon:stdio ... [ 0.000000][ T0] Linux version 7.0.0-rc4-dirty (nathan@framework-amd-ryzen-maxplus-395) (powerpc64-linux-gcc (GCC) 15.2.0, GNU ld (GNU Binutils) 2.45) #1 SMP PREEMPT Thu Mar 19 15:45:53 MST 2026 ... [ 0.216764][ T1] vgaarb: loaded [ 0.217590][ T1] clocksource: Switched to clocksource timebase [ 0.221007][ T12] BUG: Kernel NULL pointer dereference at 0x00000010 [ 0.221049][ T12] Faulting instruction address: 0xc00000000044947c [ 0.221237][ T12] Oops: Kernel access of bad area, sig: 11 [#1] [ 0.221276][ T12] BE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries [ 0.221359][ T12] Modules linked in: [ 0.221556][ T12] CPU: 0 UID: 0 PID: 12 Comm: kworker/u4:0 Not tainted 7.0.0-rc4-dirty #1 PREEMPTLAZY [ 0.221631][ T12] Hardware name: IBM pSeries (emulated by qemu) POWER8 (architected) 0x4d0200 0xf000004 of:SLOF,HEAD pSeries [ 0.221765][ T12] Workqueue: trace_init_wq tracer_init_tracefs_work_func [ 0.222065][ T12] NIP: c00000000044947c LR: c00000000041a584 CTR: c00000000053aa90 [ 0.222084][ T12] REGS: c000000003bc7960 TRAP: 0380 Not tainted (7.0.0-rc4-dirty) [ 0.222111][ T12] MSR: 8000000000009032 CR: 44000204 XER: 00000000 [ 0.222287][ T12] CFAR: c000000000449420 IRQMASK: 0 [ 0.222287][ T12] GPR00: c00000000041a584 c000000003bc7c00 c000000001c08100 c000000002892f20 [ 0.222287][ T12] GPR04: c0000000019cfa68 c0000000019cfa60 0000000000000001 0000000000000064 [ 0.222287][ T12] GPR08: 0000000000000002 0000000000000000 c000000003bba000 0000000000000010 [ 0.222287][ T12] GPR12: c00000000053aa90 c000000002c50000 c000000001ab25f8 c000000001626690 [ 0.222287][ T12] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.222287][ T12] GPR20: c000000001624868 c000000001ab2708 c0000000019cfa08 c000000001a00d18 [ 0.222287][ T12] GPR24: c0000000019cfa18 fffffffffffffef7 c000000003051205 c0000000019cfa68 [ 0.222287][ T12] GPR28: 0000000000000000 c0000000019cfa60 c000000002894e90 0000000000000000 [ 0.222526][ T12] NIP [c00000000044947c] __find_event_file+0x9c/0x110 [ 0.222572][ T12] LR [c00000000041a584] init_tracer_tracefs+0x274/0xcc0 [ 0.222643][ T12] Call Trace: [ 0.222690][ T12] [c000000003bc7c00] [c000000000b943b0] tracefs_create_file+0x1a0/0x2b0 (unreliable) [ 0.222766][ T12] [c000000003bc7c50] [c00000000041a584] init_tracer_tracefs+0x274/0xcc0 [ 0.222791][ T12] [c000000003bc7dc0] [c000000002046f1c] tracer_init_tracefs_work_func+0x50/0x320 [ 0.222809][ T12] [c000000003bc7e50] [c000000000276958] process_one_work+0x1b8/0x530 [ 0.222828][ T12] [c000000003bc7f10] [c00000000027778c] worker_thread+0x1dc/0x3d0 [ 0.222883][ T12] [c000000003bc7f90] [c000000000284c44] kthread+0x194/0x1b0 [ 0.222900][ T12] [c000000003bc7fe0] [c00000000000cf30] start_kernel_thread+0x14/0x18 [ 0.222961][ T12] Code: 7c691b78 7f63db78 2c090000 40820018 e89c0000 49107f21 60000000 2c030000 41820048 ebff0000 7c3ff040 41820038 7fa3eb78 81490058 e8890018 [ 0.223190][ T12] ---[ end trace 0000000000000000 ]--- ... Interestingly, turning on CONFIG_KASAN appears to hide this, maybe pointing to some sort of memory corruption (or something timing related)? If there is any other information I can provide, I am more than happy to do so. [1]: https://lore.kernel.org/20260227153730.1556542-4-mathieu.desnoyers@efficios.com/ [2]: https://lore.kernel.org/20260304-vdso-sparc64-generic-2-v6-3-d8eb3b0e1410@linutronix.de/ [3]: https://lore.kernel.org/20260311125539.4123672-2-mclapinski@google.com/ Cheers, Nathan