Re: kmemleaks on ac3b43283923 ("module: replace module_layout with module_memory")

From: jim . cromie
Date: Fri Mar 31 2023 - 17:44:16 EST


On Fri, Mar 31, 2023 at 1:12 PM Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote:
>
> On Fri, Mar 31, 2023 at 11:08:23AM -0600, jim.cromie@xxxxxxxxx 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/0x20e0
>
> Can you do:
>
> gdb vmlinux
> l *(load_module+0x188b)
>
> And provide the output?

(gdb) l *(load_module+0x188b)
0xffffffff8122a4bb is in load_module
(/home/jimc/projects/lx/wk-next/kernel/module/main.c:2820).
2815 goto free_modinfo;
2816
2817 flush_module_icache(mod);
2818
2819 /* Now copy in args */
2820 mod->args = strndup_user(uargs, ~0UL >> 1);
2821 if (IS_ERR(mod->args)) {
2822 err = PTR_ERR(mod->args);
2823 goto free_arch_cleanup;
2824 }

>
> > }, '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/0x6e0
>
> Ok that is a specific enough hint. I'll take a review of this sysfs
> path see what changed that could break.

(gdb) l *(mod_sysfs_setup+0xa9)
0xffffffff8122d2d9 is in mod_sysfs_setup
(/home/jimc/projects/lx/wk-next/kernel/module/sysfs.c:361).
356
357 mod->mkobj.mod = mod;
358
359 memset(&mod->mkobj.kobj, 0, sizeof(mod->mkobj.kobj));
360 mod->mkobj.kobj.kset = module_kset;
361 err = kobject_init_and_add(&mod->mkobj.kobj, &module_ktype, NULL,
362 "%s", mod->name);
363 if (err)
364 mod_kobject_put(mod);
365
(gdb)

>
> > [<00000000d6f7187b>] load_module+0x1de3/0x20e0

(gdb) l *(load_module+0x1de3)
0xffffffff8122aa13 is in load_module
(/home/jimc/projects/lx/wk-next/kernel/module/main.c:2856).
2851 pr_warn("%s: parameters '%s' after `--' ignored\n",
2852 mod->name, after_dashes);
2853 }
2854
2855 /* Link in to sysfs. */
2856 err = mod_sysfs_setup(mod, info, mod->kp, mod->num_kp);
2857 if (err < 0)
2858 goto coming_cleanup;
2859
2860 if (is_livepatch_module(mod)) {



> > [<0000000074361279>] __do_sys_finit_module+0x93/0xf0
> > [<000000004caeb948>] do_syscall_64+0x34/0x80
> > [<000000009f5d036c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0' => 16
> > },
>> Luis