From: ebiederm@xmission.com (Eric W. Biederman)
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-kernel@vger.kernel.org, "majianpeng" <majianpeng@gmail.com>
Subject: Re: Possible memory leaks in proc_sysctl.c
Date: Wed, 18 Apr 2012 06:22:09 -0700 [thread overview]
Message-ID: <m1wr5d18fy.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20120418101231.GE1505@arm.com> (Catalin Marinas's message of "Wed, 18 Apr 2012 11:12:31 +0100")
Catalin Marinas <catalin.marinas@arm.com> writes:
> Hi Eric,
>
> Following your commit f728019bb (sysctl: register only tables of sysctl
> files), I get several kmemleak reports. They all seem to be header
> allocations with kzalloc() in __register_sysctl_table() and
> __register_sysctl_paths(). The patch isn't simple to quickly figure out
> what may be wrong.
Due to a change in the data structure places where we register the
sysctl permanently and ignore the result from the register_sysctl_...
family of functions now report this leak.
majianpeng has done a good of getting kmemleak_not_leak annotations into
the net tree, and I have one of his patches pending to put into my
sysctl tree (see below).
I don't know if the issue is serious enough to warrant putting the
changes into 3.4 but the patches are trivial.
The pending patch for kernel/sysctl.c
Eric
>From 349f2cf150ba9aabdcc24c174f7dab09d3da4508 Mon Sep 17 00:00:00 2001
From: majianpeng <majianpeng@gmail.com>
Date: Tue, 17 Apr 2012 13:45:52 +0800
Subject: [PATCH] sysctl:Remove memleak reports by kmemeleak_not_leak
Signed-off-by: majianpeng <majianpeng@gmail.com>
---
kernel/sysctl.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 4ab1187..136ac3b 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1551,7 +1551,7 @@ static struct ctl_table dev_table[] = {
int __init sysctl_init(void)
{
- register_sysctl_table(sysctl_base_table);
+ kmemleak_not_leak(register_sysctl_table(sysctl_base_table));
return 0;
}
> Tested on an ARM platform with 3.4-rc3.
>
> unreferenced object 0xbf86c380 (size 128):
> comm "swapper/0", pid 0, jiffies 4294937306 (age 69938.200s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00 00 00 00 2c eb 4c 80 00 00 00 00 00 00 00 00 ....,.L.........
> backtrace:
> [<800be064>] create_object+0xe8/0x224
> [<800bb120>] __kmalloc+0x118/0x19c
> [<801116b8>] __register_sysctl_paths+0x128/0x1d0
> [<8048a248>] sysctl_init+0xc/0x18
> [<80483810>] start_kernel+0x310/0x32c
> [<60008044>] 0x60008044
> [<ffffffff>] 0xffffffff
> unreferenced object 0xbf862380 (size 64):
> comm "swapper/0", pid 0, jiffies 4294937306 (age 69938.200s)
> hex dump (first 32 bytes):
> 84 bf 4e 80 00 00 00 00 01 00 00 00 01 00 00 00 ..N.............
> 00 00 00 00 00 00 00 00 28 31 4d 80 28 31 4d 80 ........(1M.(1M.
> backtrace:
> [<800be064>] create_object+0xe8/0x224
> [<800bb120>] __kmalloc+0x118/0x19c
> [<80110f5c>] __register_sysctl_table+0x4c/0x468
> [<801114a4>] register_leaf_sysctl_tables+0x12c/0x200
> [<8011151c>] register_leaf_sysctl_tables+0x1a4/0x200
> [<801116e4>] __register_sysctl_paths+0x154/0x1d0
> [<8048a248>] sysctl_init+0xc/0x18
> [<80483810>] start_kernel+0x310/0x32c
> [<60008044>] 0x60008044
> [<ffffffff>] 0xffffffff
> unreferenced object 0xbf8623c0 (size 64):
> comm "swapper/0", pid 0, jiffies 4294937306 (age 69938.200s)
> hex dump (first 32 bytes):
> a8 bf 4e 80 00 00 00 00 01 00 00 00 01 00 00 00 ..N.............
> 00 00 00 00 00 00 00 00 28 31 4d 80 28 31 4d 80 ........(1M.(1M.
> backtrace:
> [<800be064>] create_object+0xe8/0x224
> [<800bb120>] __kmalloc+0x118/0x19c
> [<80110f5c>] __register_sysctl_table+0x4c/0x468
> [<801114a4>] register_leaf_sysctl_tables+0x12c/0x200
> [<8011151c>] register_leaf_sysctl_tables+0x1a4/0x200
> [<801116e4>] __register_sysctl_paths+0x154/0x1d0
> [<8048a248>] sysctl_init+0xc/0x18
> [<80483810>] start_kernel+0x310/0x32c
> [<60008044>] 0x60008044
> [<ffffffff>] 0xffffffff
> unreferenced object 0xbf973380 (size 64):
> comm "swapper/0", pid 1, jiffies 4294937392 (age 69937.350s)
> hex dump (first 32 bytes):
> c0 06 50 80 00 00 00 00 01 00 00 00 01 00 00 00 ..P.............
> 00 00 00 00 c0 06 50 80 28 31 4d 80 28 31 4d 80 ......P.(1M.(1M.
> backtrace:
> [<800be064>] create_object+0xe8/0x224
> [<800bb120>] __kmalloc+0x118/0x19c
> [<80110f5c>] __register_sysctl_table+0x4c/0x468
> [<80111754>] __register_sysctl_paths+0x1c4/0x1d0
> [<8049aa54>] sysctl_core_init+0x1c/0x38
> [<800086dc>] do_one_initcall+0x34/0x17c
> [<804839a0>] kernel_init+0x174/0x21c
> [<8000f978>] kernel_thread_exit+0x0/0x8
> [<ffffffff>] 0xffffffff
> unreferenced object 0xbfa27280 (size 64):
> comm "swapper/0", pid 1, jiffies 4294937393 (age 69937.340s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00 00 00 00 80 33 4e 80 00 00 00 00 00 00 00 00 .....3N.........
> backtrace:
> [<800be064>] create_object+0xe8/0x224
> [<800bb120>] __kmalloc+0x118/0x19c
> [<801116b8>] __register_sysctl_paths+0x128/0x1d0
> [<8049c810>] inet_init+0xa8/0x28c
> [<800086dc>] do_one_initcall+0x34/0x17c
> [<804839a0>] kernel_init+0x174/0x21c
> [<8000f978>] kernel_thread_exit+0x0/0x8
> [<ffffffff>] 0xffffffff
> unreferenced object 0xbfa27100 (size 64):
> comm "swapper/0", pid 1, jiffies 4294937393 (age 69937.340s)
> hex dump (first 32 bytes):
> 18 0d 50 80 00 00 00 00 01 00 00 00 01 00 00 00 ..P.............
> 00 00 00 00 00 00 00 00 28 31 4d 80 28 31 4d 80 ........(1M.(1M.
> backtrace:
> [<800be064>] create_object+0xe8/0x224
> [<800bb120>] __kmalloc+0x118/0x19c
> [<80110f5c>] __register_sysctl_table+0x4c/0x468
> [<801114a4>] register_leaf_sysctl_tables+0x12c/0x200
> [<8011151c>] register_leaf_sysctl_tables+0x1a4/0x200
> [<801116e4>] __register_sysctl_paths+0x154/0x1d0
> [<8049c810>] inet_init+0xa8/0x28c
> [<800086dc>] do_one_initcall+0x34/0x17c
> [<804839a0>] kernel_init+0x174/0x21c
> [<8000f978>] kernel_thread_exit+0x0/0x8
> [<ffffffff>] 0xffffffff
>
>
> Thanks.
next prev parent reply other threads:[~2012-04-18 13:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-18 10:12 Possible memory leaks in proc_sysctl.c Catalin Marinas
2012-04-18 13:22 ` Eric W. Biederman [this message]
2012-04-18 14:18 ` Catalin Marinas
2012-04-18 14:52 ` Eric W. Biederman
2012-04-18 15:15 ` Catalin Marinas
2012-04-18 15:44 ` Eric W. Biederman
2012-04-18 16:14 ` 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=m1wr5d18fy.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=catalin.marinas@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=majianpeng@gmail.com \
/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