* [RFC] kmemleak: Is DMI supported ?
@ 2010-03-11 17:34 Eric Dumazet
2010-03-12 9:54 ` Catalin Marinas
0 siblings, 1 reply; 2+ messages in thread
From: Eric Dumazet @ 2010-03-11 17:34 UTC (permalink / raw)
To: Catalin Marinas; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [RFC] kmemleak: Is DMI supported ?
2010-03-11 17:34 [RFC] kmemleak: Is DMI supported ? Eric Dumazet
@ 2010-03-12 9:54 ` Catalin Marinas
0 siblings, 0 replies; 2+ messages in thread
From: Catalin Marinas @ 2010-03-12 9:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2010-03-12 9:54 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-03-11 17:34 [RFC] kmemleak: Is DMI supported ? Eric Dumazet
2010-03-12 9:54 ` Catalin Marinas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®