LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Mathieu Malaterre <malat@debian.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: kmemleak: 1157 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
Date: Tue, 28 May 2019 15:21:14 +1000	[thread overview]
Message-ID: <87tvdfp31x.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <CA+7wUsw_jkgWfknXbpK7_yfy=S5Y0jvQe1KP3kM-LT8fFnUF5g@mail.gmail.com>

Mathieu Malaterre <malat@debian.org> writes:
> Hi there,
>
> Is there a way to dump more context (somewhere in of tree
> flattening?). I cannot make sense of the following:

Hmm. Not that I know of.

Those don't look related to OF flattening/unflattening. That's just
sysfs setup based on the unflattened device tree.

The allocations are happening in safe_name() AFAICS.

int __of_add_property_sysfs(struct device_node *np, struct property *pp)
{
	...
	pp->attr.attr.name = safe_name(&np->kobj, pp->name);

And the free is in __of_sysfs_remove_bin_file():

void __of_sysfs_remove_bin_file(struct device_node *np, struct property *prop)
{
	if (!IS_ENABLED(CONFIG_SYSFS))
		return;

	sysfs_remove_bin_file(&np->kobj, &prop->attr);
	kfree(prop->attr.attr.name);


There is this check which could be failing leading to us not calling the
free at all:

void __of_remove_property_sysfs(struct device_node *np, struct property *prop)
{
	/* at early boot, bail here and defer setup to of_init() */
	if (of_kset && of_node_is_attached(np))
		__of_sysfs_remove_bin_file(np, prop);
}


So maybe stick a printk() in there to see if you're hitting that
condition, eg something like:

	if (of_kset && of_node_is_attached(np))
		__of_sysfs_remove_bin_file(np, prop);
	else
		printk("%s: leaking prop %s on node %pOF\n", __func__, prop->attr.attr.name, np);


cheers

> kmemleak: 1157 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
>
> Where:
>
> # head -40 /sys/kernel/debug/kmemleak
> unreferenced object 0xdf44d180 (size 8):
>   comm "swapper", pid 1, jiffies 4294892297 (age 4766.460s)
>   hex dump (first 8 bytes):
>     62 61 73 65 00 00 00 00                          base....
>   backtrace:
>     [<0ca59825>] kstrdup+0x4c/0xb8
>     [<c8a79377>] kobject_set_name_vargs+0x34/0xc8
>     [<661b4c86>] kobject_add+0x78/0x120
>     [<c1416f27>] __of_attach_node_sysfs+0xa0/0x14c
>     [<2a143d10>] of_core_init+0x90/0x114
>     [<a353d0e1>] driver_init+0x30/0x48
>     [<84ed01b1>] kernel_init_freeable+0xfc/0x3fc
>     [<dc60f815>] kernel_init+0x20/0x110
>     [<faa1c5b0>] ret_from_kernel_thread+0x14/0x1c
> unreferenced object 0xdf44d178 (size 8):
>   comm "swapper", pid 1, jiffies 4294892297 (age 4766.460s)
>   hex dump (first 8 bytes):
>     6d 6f 64 65 6c 00 97 c8                          model...
>   backtrace:
>     [<0ca59825>] kstrdup+0x4c/0xb8
>     [<0eeb0a3b>] __of_add_property_sysfs+0x88/0x12c
>     [<f6c64af0>] __of_attach_node_sysfs+0xcc/0x14c
>     [<2a143d10>] of_core_init+0x90/0x114
>     [<a353d0e1>] driver_init+0x30/0x48
>     [<84ed01b1>] kernel_init_freeable+0xfc/0x3fc
>     [<dc60f815>] kernel_init+0x20/0x110
>     [<faa1c5b0>] ret_from_kernel_thread+0x14/0x1c
> unreferenced object 0xdf4021e0 (size 16):
>   comm "swapper", pid 1, jiffies 4294892297 (age 4766.460s)
>   hex dump (first 16 bytes):
>     63 6f 6d 70 61 74 69 62 6c 65 00 01 00 00 00 00  compatible......
>   backtrace:
>     [<0ca59825>] kstrdup+0x4c/0xb8
>     [<0eeb0a3b>] __of_add_property_sysfs+0x88/0x12c
>     [<f6c64af0>] __of_attach_node_sysfs+0xcc/0x14c
>     [<2a143d10>] of_core_init+0x90/0x114
>     [<a353d0e1>] driver_init+0x30/0x48
>     [<84ed01b1>] kernel_init_freeable+0xfc/0x3fc
>     [<dc60f815>] kernel_init+0x20/0x110
>     [<faa1c5b0>] ret_from_kernel_thread+0x14/0x1c

  reply	other threads:[~2019-05-28  5:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-23  8:38 kmemleak: 1157 new suspected memory leaks (see /sys/kernel/debug/kmemleak) Mathieu Malaterre
2019-05-28  5:21 ` Michael Ellerman [this message]
2019-05-28 19:14   ` Mathieu Malaterre
2019-05-29 17:04     ` Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tvdfp31x.fsf@concordia.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=malat@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox