[RFC] kmemleak: Is DMI supported ?

[Eric Dumazet]

Hi Catalin

On my i686 machine, I have
CONFIG_DMI=y

and 12 entries in /sys/firmware/memmap/ like first one named "0" :

$ grep . /sys/firmware/memmap/0/*
/sys/firmware/memmap/0/end:0x9f3ff
/sys/firmware/memmap/0/start:0x0
/sys/firmware/memmap/0/type:System RAM

All 12 kobjects are allocated in DMI zone between
c1001000 b .brk.dmi_alloc
c1011000 B __brk_limit)

see arch/x86/kernel/setup.c:124

#ifdef CONFIG_DMI
RESERVE_BRK(dmi_alloc, 65536);
#endif

Still kmemleak seems to thing their names are unreferenced objects.

unreferenced object 0xf6a4bcd8 (size 8):
comm "swapper", pid 1, jiffies 4294669233 (age 2454.223s)
hex dump (first 8 bytes):
31 31 00 f6 00 00 00 00 11......
backtrace:
[<c05a5bc5>] kmemleak_alloc+0x45/0x60
[<c02dcfa2>] __kmalloc+0x122/0x1f0
[<c039fe00>] kvasprintf+0x30/0x50
[<c0397469>] kobject_set_name_vargs+0x49/0xa0
[<c03974e1>] kobject_add_varg+0x21/0x50
[<c039756c>] kobject_add+0x2c/0x60
[<c04bed4c>] add_sysfs_fw_map_entry+0x4c/0x90
[<c07ec523>] memmap_init+0x13/0x2d
[<c0201038>] do_one_initcall+0x28/0x180
[<c07c539d>] kernel_init+0x140/0x1df
[<c02030fa>] kernel_thread_helper+0x6/0x10
[<ffffffff>] 0xffffffff

Any idea how to include dmi_alloc zone in kmemleak logic ?

Thanks

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

[Catalin Marinas]

Hi Eric,

On Thu, 2010-03-11 at 17:34 +0000, Eric Dumazet wrote:
> On my i686 machine, I have
> CONFIG_DMI=y
>
> and 12 entries in /sys/firmware/memmap/ like first one named "0" :
>
> $ grep . /sys/firmware/memmap/0/*
> /sys/firmware/memmap/0/end:0x9f3ff
> /sys/firmware/memmap/0/start:0x0
> /sys/firmware/memmap/0/type:System RAM
>
>
> All 12 kobjects are allocated in DMI zone between
> c1001000 b .brk.dmi_alloc
> c1011000 B __brk_limit)
>
> see arch/x86/kernel/setup.c:124
>
> #ifdef CONFIG_DMI
> RESERVE_BRK(dmi_alloc, 65536);
> #endif
>
> Still kmemleak seems to thing their names are unreferenced objects.

By default, kmemleak only scans the Data and BSS sections, any other
memory block that's not allocated via slab needs to be added explicitly.
In this case, you can add the line below somewhere in the x86 setup.c
file:

kmemleak_alloc(dmi_alloc, 65536, 0, 0);

An alternative would be to add x86 brk scanning explicitly in
kmemleak.c. It has the advantage that only the initialised parts of the
BRK are scanned. Something like below (untested):

diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 5b069e4..2183f99 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -98,6 +98,9 @@
#include <asm/sections.h>
#include <asm/processor.h>
#include <asm/atomic.h>
+#ifdef CONFIG_X86
+#include <asm/setup.h>
+#endif

#include <linux/kmemcheck.h>
#include <linux/kmemleak.h>
@@ -1166,6 +1169,9 @@ static void kmemleak_scan(void)
/* data/bss scanning */
scan_block(_sdata, _edata, NULL, 1);
scan_block(__bss_start, __bss_stop, NULL, 1);
+#ifdef CONFIG_X86
+ scan_block(__brk_base, _brk_end, NULL, 1);
+#endif

#ifdef CONFIG_SMP
/* per-cpu sections scanning */

--
Catalin