linux-kernel - Re: [PATCH] sysctl: Suppress kmemleak messages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20120522094757.GA28761@arm.com>
Date:	Tue, 22 May 2012 10:47:57 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] sysctl: Suppress kmemleak messages

On Tue, May 22, 2012 at 02:04:17AM +0100, Steven Rostedt wrote:
> Not sure who the owner is of kernel/sysctl.c, so I'm just sending this
> patch to you :-)
> 
> The register_sysctl_table() is a strange function, as it makes internal
> allocations (a header) to register a sysctl_table. This header is a
> handle to the table that is created, and can be used to unregister the
> table. But if the table is permanent and never unregistered, the header
> acts the same as a static variable.
> 
> Unfortunately, this allocation of memory that is never expected to be
> freed, fools kmemleak in thinking that we have leaked memory. For those
> sysctl tables that are never unregistered, and have no pointer
> referencing them, kmemleak will think that these are memory leaks:
> 
> unreferenced object 0xffff880079fb9d40 (size 192):
>   comm "swapper/0", pid 0, jiffies 4294667316 (age 12614.152s)
>   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 00 00 00 00 00 00 00 00 00 00 00 00  ................
>   backtrace:
>     [<ffffffff8146b590>] kmemleak_alloc+0x73/0x98
>     [<ffffffff8110a935>] kmemleak_alloc_recursive.constprop.42+0x16/0x18
>     [<ffffffff8110b852>] __kmalloc+0x107/0x153
>     [<ffffffff8116fa72>] kzalloc.constprop.8+0xe/0x10
>     [<ffffffff811703c9>] __register_sysctl_paths+0xe1/0x160
>     [<ffffffff81170463>] register_sysctl_paths+0x1b/0x1d
>     [<ffffffff8117047d>] register_sysctl_table+0x18/0x1a
>     [<ffffffff81afb0a1>] sysctl_init+0x10/0x14
>     [<ffffffff81b05a6f>] proc_sys_init+0x2f/0x31
>     [<ffffffff81b0584c>] proc_root_init+0xa5/0xa7
>     [<ffffffff81ae5b7e>] start_kernel+0x3d0/0x40a
>     [<ffffffff81ae52a7>] x86_64_start_reservations+0xae/0xb2
>     [<ffffffff81ae53ad>] x86_64_start_kernel+0x102/0x111
>     [<ffffffffffffffff>] 0xffffffffffffffff
> 
> 
> The sysctl_base_table used by sysctl itself is one such instance that
> registers the table to never be unregistered.
> 
> Use kmemleak_not_leak() to suppress the kmemleak false positive.
> 
> [ applied against 3.4 ]
> 
> Signed-off-by: Steven Rostedt <rostedt@...dmis.org>

FWIW,

Acked-by: Catalin Marinas <catalin.marinas@....com>

(for the use of the kmemleak API :))

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/