From: Catalin Marinas <catalin.marinas@arm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org
Subject: Possible memory leaks in proc_sysctl.c
Date: Wed, 18 Apr 2012 11:12:31 +0100 [thread overview]
Message-ID: <20120418101231.GE1505@arm.com> (raw)
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.
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.
--
Catalin
next reply other threads:[~2012-04-18 10:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-18 10:12 Catalin Marinas [this message]
2012-04-18 13:22 ` Possible memory leaks in proc_sysctl.c Eric W. Biederman
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=20120418101231.GE1505@arm.com \
--to=catalin.marinas@arm.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.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