Prev: sysfs: use sysfs_bin_attr_init in firmware class driver
Next: [tip:x86/urgent] x86, UV: Fix target_cpus() in x2apic_uv_x.c
From: Catalin Marinas on 12 Mar 2010 05:00 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |