All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.