-
-
Notifications
You must be signed in to change notification settings - Fork 51
Description
The CI reports this issues and it can reproduce it all the time:
unreferenced object 0xffff888009cedc00 (size 256):
comm "swapper/0", pid 1, jiffies 4294693823 (age 73.764s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 48 00 00 00 00 00 00 00 ........H.......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
msr_build_context (include/linux/slab.h:621)
pm_check_save_msr (arch/x86/power/cpu.c:520)
do_one_initcall (init/main.c:1298)
kernel_init_freeable (init/main.c:1370)
kernel_init (init/main.c:1504)
ret_from_fork (arch/x86/entry/entry_64.S:304)
After investigation on my side, git bisect reports the issue has been introduced by e2a1256 ("x86/speculation: Restore speculation related MSRs during S3 resume"). Reverting this commit indeed helps.
It looks like a false positive: an array is allocated but never freed. It doesn't need to be freed in fact and it is still attached to a static variable so no need to worry about it. The origin of the issue is then 7a9c2dd ("x86/pm: Introduce quirk framework to save/restore extra MSR registers around suspend/resume").
Just strange I cannot find other reports elsewhere. Just a few mentions but no fixes: https://lkml.org/lkml/2022/1/11/116 & https://www.mail-archive.com/[email protected]/msg2164453.html
Maybe only visible because of our kconfig (mainly: x86_64_defconfig + virt + debug (- slab_debug) + mptcp)?