public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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