Re: kmemleaks on ac3b43283923 ("module: replace module_layout with module_memory")
From: Luis Chamberlain <mcgrof@kernel.org>
Date: 2023-03-31 19:12:22
Also in:
lkml
On Fri, Mar 31, 2023 at 11:08:23AM -0600, jim.cromie@gmail.com wrote:
:#> uptime 09:45:32 up 1 day, 23:07, 0 users, load average: 0.07, 0.04, 0.01 :#> uname -a Linux (none) 6.3.0-rc1-f2-00001-gac3b43283923 #359 SMP PREEMPT_DYNAMIC Wed Mar 29 09:33:11 MDT 2023 x86_64 x86_64 x86_64 GNU/Linux the leaks I sent previously might be from/on a different commit, heres the relevant one fwiw, the config is unremarkable. it started with CONFIG_BUILD_SALT="5.16.8-200.fc35.x86_64" then `make localmodconfig` to drop anything I dont have hw for then `virtme-configkernel --update` to pick up the 9p,etc config options And some extra DEBUG_* options If you'd like to see runs with others, or see the config itself, please ask.
If you wanna see things explode echo 0 > /proc/sys/vm/oom_dump_tasks ./stress-ng --module 20 --module-name xfs This assumes xfs is not already loaded, and has all dependencies already loaded. What would test the load_module() path. If you wanna see if the test is earlier, you can try a module which is already loaded on your system.
:#> uname -a
Linux (none) 6.3.0-rc1-f2-00001-gac3b43283923 #359 SMP PREEMPT_DYNAMIC
Wed Mar 29 09:33:11 MDT 2023 x86_64 x86_64 x86_64 GNU/Linux
:#> ./grok_kmemleak -n
not: bless( {
'backtraces' => {
'[<0000000058fb276d>] __kmalloc_node_track_caller+0x4a/0x140
[<00000000a2f80203>] memdup_user+0x26/0x90
[<00000000f7cd3624>] strndup_user+0x3f/0x60
[<0000000098fd26c5>] load_module+0x188b/0x20e0Can you do: gdb vmlinux l *(load_module+0x188b) And provide the output?
}, 'LeakSet' )
mods: bless( {
'backtraces' => {
'[<0000000058fb276d>] __kmalloc_node_track_caller+0x4a/0x140
[<00000000ab7b01fd>] kstrdup+0x32/0x60
[<000000005ed25b98>] kobject_set_name_vargs+0x1c/0x90
[<0000000090fe19ca>] kobject_init_and_add+0x4d/0x90
[<0000000045666935>] mod_sysfs_setup+0xa9/0x6e0Ok that is a specific enough hint. I'll take a review of this sysfs path see what changed that could break.
[<00000000d6f7187b>] load_module+0x1de3/0x20e0
[<0000000074361279>] __do_sys_finit_module+0x93/0xf0
[<000000004caeb948>] do_syscall_64+0x34/0x80
[<000000009f5d036c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0' => 16
},Luis