Bug 205327

Summary: kmemleak reports various leaks in "swapper/0"
Product: Platform Specific/Hardware Reporter: Erhard F. (erhard_f)
Component: PPC-64Assignee: platform_ppc-64
Status: RESOLVED CODE_FIX    
Severity: normal CC: michael
Priority: P1    
Hardware: PPC-64   
OS: Linux   
Kernel Version: 5.4-rc4 Subsystem:
Regression: No Bisected commit-id:
Attachments: kmemleak output
5.4.0-rc4 kernel .config (PowerMac G5 7,3)
dmesg (kernel 5.4.0-rc4, PowerMac G5 7,3)

Description Erhard F. 2019-10-26 19:30:11 UTC
Created attachment 285655 [details]
kmemleak output

kmemleak reported various leaks in "swapper/0" while I was building some stuff via distcc:

unreferenced object 0xc00000027eea64e0 (size 32):
  comm "swapper/0", pid 1, jiffies 4294877673 (age 1568.254s)
  hex dump (first 32 bytes):
    2f 5f 5f 6c 6f 63 61 6c 5f 66 69 78 75 70 73 5f  /__local_fixups_
    5f 00 00 00 00 ca ad c8 00 00 00 00 00 00 00 00  _...............
  backtrace:
    [<00000000e9188659>] .kvasprintf+0x64/0xe0
    [<00000000dc0cdc16>] .kasprintf+0x2c/0x50
    [<0000000000808425>] .attach_node_and_children+0x2c/0x270
    [<00000000a50a500b>] .of_unittest+0x1f4/0x379c
    [<00000000e51cf048>] .do_one_initcall+0x7c/0x430
    [<00000000e6d8e44a>] .kernel_init_freeable+0x2d0/0x3cc
    [<000000005adf1660>] .kernel_init+0x1c/0x138
    [<000000006adcb060>] .ret_from_kernel_thread+0x58/0x64
[...]
Comment 1 Erhard F. 2019-10-26 19:31:45 UTC
Created attachment 285659 [details]
5.4.0-rc4 kernel .config (PowerMac G5 7,3)
Comment 2 Erhard F. 2019-10-26 19:50:01 UTC
Created attachment 285661 [details]
dmesg (kernel 5.4.0-rc4, PowerMac G5 7,3)
Comment 3 Michael Ellerman 2019-10-29 11:27:47 UTC
That looks like a pretty straight forward memory leak here:

static void attach_node_and_children(struct device_node *np)
{
	struct device_node *next, *dup, *child;
	unsigned long flags;
	const char *full_name;

	full_name = kasprintf(GFP_KERNEL, "%pOF", np);

	if (!strcmp(full_name, "/__local_fixups__") ||
	    !strcmp(full_name, "/__fixups__"))

>> missing kfree(full_name);

		return;

	dup = of_find_node_by_path(full_name);
	kfree(full_name);
	if (dup) {
		update_node_properties(np, dup);
		return;
	}


Do you want to send a patch?
Comment 4 Erhard F. 2019-10-31 01:22:40 UTC
(In reply to Michael Ellerman from comment #3)
> That looks like a pretty straight forward memory leak here:
[...]
> Do you want to send a patch?
Thanks for pointing out! Yes, in this case writing a patch is within reach of my coding skills. ;)

Have to check the procedure of how to submit a patch to the kernel first, as I have not done this yet.
Comment 5 Erhard F. 2019-11-18 19:17:08 UTC
(In reply to Michael Ellerman from comment #3)
> Do you want to send a patch?
I already sent the patch to linuxppc-dev@lists.ozlabs.org (https://patchwork.ozlabs.org/patch/1195212/) but don't know how to proceed further to get this patch into stable, etc.
Comment 6 Michael Ellerman 2019-11-19 01:26:14 UTC
I replied with directions on what to do.
Comment 7 Erhard F. 2020-01-05 12:46:16 UTC
Fix landed in 5.4.8 and older affected LTS kernels.