60 memory leaks.. or is it some thing wrong with kmemleak?

60 memory leaks.. or is it some thing wrong with kmemleak?

[Alexey Fisher]

Hallo all,
i enabled kmemleak and now i get a lot of them...
i do not know if this are real or some noise..
most of the about mounting ext4

unreferenced object 0xffff880133c63800 (size 1024):
   comm "exe", pid 1521, jiffies 4294894652
   backtrace:
     [<ffffffff810f8f36>] create_object+0x126/0x2b0
     [<ffffffff810f91d5>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f32a3>] __kmalloc+0x113/0x200
     [<ffffffff811aa061>] ext4_mb_init+0x1b1/0x570
     [<ffffffff8119b3d2>] ext4_fill_super+0x1de2/0x26d0
     [<ffffffff810fe40f>] get_sb_bdev+0x16f/0x1b0
     [<ffffffff811912f3>] ext4_get_sb+0x13/0x20
     [<ffffffff810fdee6>] vfs_kern_mount+0x76/0x180
     [<ffffffff810fe05d>] do_kern_mount+0x4d/0x120
     [<ffffffff81115e17>] do_mount+0x307/0x880
     [<ffffffff8111641f>] sys_mount+0x8f/0xe0
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff8801334db0c0 (size 192):
   comm "exe", pid 1521, jiffies 4294894652
   backtrace:
     [<ffffffff810f8f36>] create_object+0x126/0x2b0
     [<ffffffff810f91d5>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f32a3>] __kmalloc+0x113/0x200
     [<ffffffff811aa061>] ext4_mb_init+0x1b1/0x570
     [<ffffffff8119b3d2>] ext4_fill_super+0x1de2/0x26d0
     [<ffffffff810fe40f>] get_sb_bdev+0x16f/0x1b0
     [<ffffffff811912f3>] ext4_get_sb+0x13/0x20
     [<ffffffff810fdee6>] vfs_kern_mount+0x76/0x180
     [<ffffffff810fe05d>] do_kern_mount+0x4d/0x120
     [<ffffffff81115e17>] do_mount+0x307/0x880
     [<ffffffff8111641f>] sys_mount+0x8f/0xe0
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff


and other seems like about control group:


unreferenced object 0xffff88013b852440 (size 544):
   comm "swapper", pid 0, jiffies 4294892296
   backtrace:
     [<ffffffff810f8f36>] create_object+0x126/0x2b0
     [<ffffffff810f91d5>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f24f3>] kmem_cache_alloc+0xf3/0x170
     [<ffffffff8121deff>] idr_pre_get+0x5f/0x90
     [<ffffffff810898c5>] get_new_cssid+0x65/0x120
     [<ffffffff8174f7a3>] cgroup_init+0x6f/0x109
     [<ffffffff8173ad21>] start_kernel+0x3a6/0x3ca
     [<ffffffff8173a315>] x86_64_start_reservations+0x125/0x129
     [<ffffffff8173a3fd>] x86_64_start_kernel+0xe4/0xeb
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff88013b852660 (size 544):
   comm "swapper", pid 0, jiffies 4294892296
   backtrace:
     [<ffffffff810f8f36>] create_object+0x126/0x2b0
     [<ffffffff810f91d5>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f24f3>] kmem_cache_alloc+0xf3/0x170
     [<ffffffff8121deff>] idr_pre_get+0x5f/0x90
     [<ffffffff810898c5>] get_new_cssid+0x65/0x120
     [<ffffffff8174f7a3>] cgroup_init+0x6f/0x109
     [<ffffffff8173ad21>] start_kernel+0x3a6/0x3ca
     [<ffffffff8173a315>] x86_64_start_reservations+0x125/0x129
     [<ffffffff8173a3fd>] x86_64_start_kernel+0xe4/0xeb
     [<ffffffffffffffff>] 0xffffffffffffffff

Re: 60 memory leaks.. or is it some thing wrong with kmemleak?

[Pekka Enberg]

Hi Alexey,

[ Lets cc Catalin. ]

On Tue, Jul 14, 2009 at 9:08 AM, Alexey
Fisher<bug-track@fisher-privat.net> wrote:
> Hallo all,
> i enabled kmemleak and now i get a lot of them...

Which kernel version is this? You almost definitely want to try out
2.6.31-rc3 which has tons of bug fixes to kmemleak.

> i do not know if this are real or some noise..
> most of the about mounting ext4
>
> unreferenced object 0xffff880133c63800 (size 1024):
>  comm "exe", pid 1521, jiffies 4294894652
>  backtrace:
>    [<ffffffff810f8f36>] create_object+0x126/0x2b0
>    [<ffffffff810f91d5>] kmemleak_alloc+0x25/0x60
>    [<ffffffff810f32a3>] __kmalloc+0x113/0x200
>    [<ffffffff811aa061>] ext4_mb_init+0x1b1/0x570
>    [<ffffffff8119b3d2>] ext4_fill_super+0x1de2/0x26d0
>    [<ffffffff810fe40f>] get_sb_bdev+0x16f/0x1b0
>    [<ffffffff811912f3>] ext4_get_sb+0x13/0x20
>    [<ffffffff810fdee6>] vfs_kern_mount+0x76/0x180
>    [<ffffffff810fe05d>] do_kern_mount+0x4d/0x120
>    [<ffffffff81115e17>] do_mount+0x307/0x880
>    [<ffffffff8111641f>] sys_mount+0x8f/0xe0
>    [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
>    [<ffffffffffffffff>] 0xffffffffffffffff
> unreferenced object 0xffff8801334db0c0 (size 192):
>  comm "exe", pid 1521, jiffies 4294894652
>  backtrace:
>    [<ffffffff810f8f36>] create_object+0x126/0x2b0
>    [<ffffffff810f91d5>] kmemleak_alloc+0x25/0x60
>    [<ffffffff810f32a3>] __kmalloc+0x113/0x200
>    [<ffffffff811aa061>] ext4_mb_init+0x1b1/0x570
>    [<ffffffff8119b3d2>] ext4_fill_super+0x1de2/0x26d0
>    [<ffffffff810fe40f>] get_sb_bdev+0x16f/0x1b0
>    [<ffffffff811912f3>] ext4_get_sb+0x13/0x20
>    [<ffffffff810fdee6>] vfs_kern_mount+0x76/0x180
>    [<ffffffff810fe05d>] do_kern_mount+0x4d/0x120
>    [<ffffffff81115e17>] do_mount+0x307/0x880
>    [<ffffffff8111641f>] sys_mount+0x8f/0xe0
>    [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
>    [<ffffffffffffffff>] 0xffffffffffffffff
>
>
> and other seems like about control group:
>
>
> unreferenced object 0xffff88013b852440 (size 544):
>  comm "swapper", pid 0, jiffies 4294892296
>  backtrace:
>    [<ffffffff810f8f36>] create_object+0x126/0x2b0
>    [<ffffffff810f91d5>] kmemleak_alloc+0x25/0x60
>    [<ffffffff810f24f3>] kmem_cache_alloc+0xf3/0x170
>    [<ffffffff8121deff>] idr_pre_get+0x5f/0x90
>    [<ffffffff810898c5>] get_new_cssid+0x65/0x120
>    [<ffffffff8174f7a3>] cgroup_init+0x6f/0x109
>    [<ffffffff8173ad21>] start_kernel+0x3a6/0x3ca
>    [<ffffffff8173a315>] x86_64_start_reservations+0x125/0x129
>    [<ffffffff8173a3fd>] x86_64_start_kernel+0xe4/0xeb
>    [<ffffffffffffffff>] 0xffffffffffffffff
> unreferenced object 0xffff88013b852660 (size 544):
>  comm "swapper", pid 0, jiffies 4294892296
>  backtrace:
>    [<ffffffff810f8f36>] create_object+0x126/0x2b0
>    [<ffffffff810f91d5>] kmemleak_alloc+0x25/0x60
>    [<ffffffff810f24f3>] kmem_cache_alloc+0xf3/0x170
>    [<ffffffff8121deff>] idr_pre_get+0x5f/0x90
>    [<ffffffff810898c5>] get_new_cssid+0x65/0x120
>    [<ffffffff8174f7a3>] cgroup_init+0x6f/0x109
>    [<ffffffff8173ad21>] start_kernel+0x3a6/0x3ca
>    [<ffffffff8173a315>] x86_64_start_reservations+0x125/0x129
>    [<ffffffff8173a3fd>] x86_64_start_kernel+0xe4/0xeb
>    [<ffffffffffffffff>] 0xffffffffffffffff
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: 60 memory leaks.. or is it some thing wrong with kmemleak?

[Alexey Fisher]

Hi Pekka,

i updated now to git 2.6.31-rc3 and now i have
"kmemleak: 76 new suspected memory leaks"

ext4 and control group still there.


Pekka Enberg schrieb:
> Hi Alexey,
> 
> [ Lets cc Catalin. ]
> 
> On Tue, Jul 14, 2009 at 9:08 AM, Alexey
> Fisher<bug-track@fisher-privat.net> wrote:
>> Hallo all,
>> i enabled kmemleak and now i get a lot of them...
> 
> Which kernel version is this? You almost definitely want to try out
> 2.6.31-rc3 which has tons of bug fixes to kmemleak.
> 
>> i do not know if this are real or some noise..
>> most of the about mounting ext4
>>
>> unreferenced object 0xffff880133c63800 (size 1024):
>>  comm "exe", pid 1521, jiffies 4294894652
>>  backtrace:
>>    [<ffffffff810f8f36>] create_object+0x126/0x2b0
>>    [<ffffffff810f91d5>] kmemleak_alloc+0x25/0x60
>>    [<ffffffff810f32a3>] __kmalloc+0x113/0x200
>>    [<ffffffff811aa061>] ext4_mb_init+0x1b1/0x570
>>    [<ffffffff8119b3d2>] ext4_fill_super+0x1de2/0x26d0
>>    [<ffffffff810fe40f>] get_sb_bdev+0x16f/0x1b0
>>    [<ffffffff811912f3>] ext4_get_sb+0x13/0x20
>>    [<ffffffff810fdee6>] vfs_kern_mount+0x76/0x180
>>    [<ffffffff810fe05d>] do_kern_mount+0x4d/0x120
>>    [<ffffffff81115e17>] do_mount+0x307/0x880
>>    [<ffffffff8111641f>] sys_mount+0x8f/0xe0
>>    [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
>>    [<ffffffffffffffff>] 0xffffffffffffffff
>> unreferenced object 0xffff8801334db0c0 (size 192):
>>  comm "exe", pid 1521, jiffies 4294894652
>>  backtrace:
>>    [<ffffffff810f8f36>] create_object+0x126/0x2b0
>>    [<ffffffff810f91d5>] kmemleak_alloc+0x25/0x60
>>    [<ffffffff810f32a3>] __kmalloc+0x113/0x200
>>    [<ffffffff811aa061>] ext4_mb_init+0x1b1/0x570
>>    [<ffffffff8119b3d2>] ext4_fill_super+0x1de2/0x26d0
>>    [<ffffffff810fe40f>] get_sb_bdev+0x16f/0x1b0
>>    [<ffffffff811912f3>] ext4_get_sb+0x13/0x20
>>    [<ffffffff810fdee6>] vfs_kern_mount+0x76/0x180
>>    [<ffffffff810fe05d>] do_kern_mount+0x4d/0x120
>>    [<ffffffff81115e17>] do_mount+0x307/0x880
>>    [<ffffffff8111641f>] sys_mount+0x8f/0xe0
>>    [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
>>    [<ffffffffffffffff>] 0xffffffffffffffff
>>
>>
>> and other seems like about control group:
>>
>>
>> unreferenced object 0xffff88013b852440 (size 544):
>>  comm "swapper", pid 0, jiffies 4294892296
>>  backtrace:
>>    [<ffffffff810f8f36>] create_object+0x126/0x2b0
>>    [<ffffffff810f91d5>] kmemleak_alloc+0x25/0x60
>>    [<ffffffff810f24f3>] kmem_cache_alloc+0xf3/0x170
>>    [<ffffffff8121deff>] idr_pre_get+0x5f/0x90
>>    [<ffffffff810898c5>] get_new_cssid+0x65/0x120
>>    [<ffffffff8174f7a3>] cgroup_init+0x6f/0x109
>>    [<ffffffff8173ad21>] start_kernel+0x3a6/0x3ca
>>    [<ffffffff8173a315>] x86_64_start_reservations+0x125/0x129
>>    [<ffffffff8173a3fd>] x86_64_start_kernel+0xe4/0xeb
>>    [<ffffffffffffffff>] 0xffffffffffffffff
>> unreferenced object 0xffff88013b852660 (size 544):
>>  comm "swapper", pid 0, jiffies 4294892296
>>  backtrace:
>>    [<ffffffff810f8f36>] create_object+0x126/0x2b0
>>    [<ffffffff810f91d5>] kmemleak_alloc+0x25/0x60
>>    [<ffffffff810f24f3>] kmem_cache_alloc+0xf3/0x170
>>    [<ffffffff8121deff>] idr_pre_get+0x5f/0x90
>>    [<ffffffff810898c5>] get_new_cssid+0x65/0x120
>>    [<ffffffff8174f7a3>] cgroup_init+0x6f/0x109
>>    [<ffffffff8173ad21>] start_kernel+0x3a6/0x3ca
>>    [<ffffffff8173a315>] x86_64_start_reservations+0x125/0x129
>>    [<ffffffff8173a3fd>] x86_64_start_kernel+0xe4/0xeb
>>    [<ffffffffffffffff>] 0xffffffffffffffff
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-testers" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 60 memory leaks.. or is it some thing wrong with kmemleak?

[Catalin Marinas]

Hi Alexey,

On Tue, 2009-07-14 at 10:28 +0200, Alexey Fisher wrote:
> i updated now to git 2.6.31-rc3 and now i have
> "kmemleak: 76 new suspected memory leaks"
> 
> ext4 and control group still there.
[...]
> > On Tue, Jul 14, 2009 at 9:08 AM, Alexey
> > Fisher<bug-track@fisher-privat.net> wrote:
> >> unreferenced object 0xffff880133c63800 (size 1024):
> >>  comm "exe", pid 1521, jiffies 4294894652
> >>  backtrace:
> >>    [<ffffffff810f8f36>] create_object+0x126/0x2b0
> >>    [<ffffffff810f91d5>] kmemleak_alloc+0x25/0x60
> >>    [<ffffffff810f32a3>] __kmalloc+0x113/0x200
> >>    [<ffffffff811aa061>] ext4_mb_init+0x1b1/0x570
> >>    [<ffffffff8119b3d2>] ext4_fill_super+0x1de2/0x26d0
> >>    [<ffffffff810fe40f>] get_sb_bdev+0x16f/0x1b0
> >>    [<ffffffff811912f3>] ext4_get_sb+0x13/0x20
> >>    [<ffffffff810fdee6>] vfs_kern_mount+0x76/0x180
> >>    [<ffffffff810fe05d>] do_kern_mount+0x4d/0x120
> >>    [<ffffffff81115e17>] do_mount+0x307/0x880
> >>    [<ffffffff8111641f>] sys_mount+0x8f/0xe0
> >>    [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
> >>    [<ffffffffffffffff>] 0xffffffffffffffff
> >> unreferenced object 0xffff8801334db0c0 (size 192):
> >>  comm "exe", pid 1521, jiffies 4294894652
> >>  backtrace:
> >>    [<ffffffff810f8f36>] create_object+0x126/0x2b0
> >>    [<ffffffff810f91d5>] kmemleak_alloc+0x25/0x60
> >>    [<ffffffff810f32a3>] __kmalloc+0x113/0x200
> >>    [<ffffffff811aa061>] ext4_mb_init+0x1b1/0x570
> >>    [<ffffffff8119b3d2>] ext4_fill_super+0x1de2/0x26d0
> >>    [<ffffffff810fe40f>] get_sb_bdev+0x16f/0x1b0
> >>    [<ffffffff811912f3>] ext4_get_sb+0x13/0x20
> >>    [<ffffffff810fdee6>] vfs_kern_mount+0x76/0x180
> >>    [<ffffffff810fe05d>] do_kern_mount+0x4d/0x120
> >>    [<ffffffff81115e17>] do_mount+0x307/0x880
> >>    [<ffffffff8111641f>] sys_mount+0x8f/0xe0
> >>    [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
> >>    [<ffffffffffffffff>] 0xffffffffffffffff

It looks more like a leak than a false positive to me but I'm not
familiar with this code. Are any of the super_block or ext4_sb_info
structure present in the reported leaks?

To prove either way, one needs to see where the reported pointers are
stored and, if they are not overwritten, why kmemleak doesn't scan the
corresponding memory (it starts from stack, data and bss sections and
any referred block is subsequently scanned).

My approach to checking whether it is a real leak or not:

     1. Run "echo scan > /sys/kernel/debug/kmemleak" a few times and
        check the debug/kmemleak file. If they are still there, it is
        not just a transient report
     2. Check the function that allocated the memory, probably
        ext4_mb_init() in this case (but there is also
        ext4_mb_init_backend which may be inlined into ext4_mb_init and
        not shown in the trace). Assuming the former, the pointers to
        the two kmalloc'ed blocks are stored in the ext4_sb_info
        structure. If there is no obvious leak on an error path, go to
        the next point
     3. Check the block that should store the pointers reported as
        leaks. If such block isn't reported as leak, it means that it is
        either scanned (and it doesn't contain those pointers - probably
        real leak) or kmemleak doesn't know about it (usually
        alloc_pages and friends since kmemleak doesn't track these). In
        the above case, both ext4_sb_info and super_block structures are
        allocated with kzalloc
     4. If one of the parent blocks is reported as a leak, start from
        point 1 with this new block (note that kmemleak always lists the
        possible leaks in the order they were allocated)
     5. Add printk("%p...") to the kernel to see exactly which block was
        suspected to be a leak. Use gdb vmlinux /proc/kcore to see the
        contents of those blocks. In my kmemleak branch
        (http://www.linux-arm.org/git?p=linux-2.6.git;a=shortlog;h=kmemleak but planned for the next merging window) I have a feature to support "echo dump=0x.... > /sys/kernel/debug/kmemleak" so that you get what information kmemleak has about such block (in the above case, the parent ext4_sb_info)

There is also a separate class of false positive caused by pointer
masquerading (not storing the real pointer) but AFAIK there was only one
case in the past which was now reworked.

> >> unreferenced object 0xffff88013b852440 (size 544):
> >>  comm "swapper", pid 0, jiffies 4294892296
> >>  backtrace:
> >>    [<ffffffff810f8f36>] create_object+0x126/0x2b0
> >>    [<ffffffff810f91d5>] kmemleak_alloc+0x25/0x60
> >>    [<ffffffff810f24f3>] kmem_cache_alloc+0xf3/0x170
> >>    [<ffffffff8121deff>] idr_pre_get+0x5f/0x90
> >>    [<ffffffff810898c5>] get_new_cssid+0x65/0x120
> >>    [<ffffffff8174f7a3>] cgroup_init+0x6f/0x109
> >>    [<ffffffff8173ad21>] start_kernel+0x3a6/0x3ca
> >>    [<ffffffff8173a315>] x86_64_start_reservations+0x125/0x129
> >>    [<ffffffff8173a3fd>] x86_64_start_kernel+0xe4/0xeb
> >>    [<ffffffffffffffff>] 0xffffffffffffffff

I get some these as well but via drm_gem_handle_create() but I couldn't
figure out whether they are real or not.

I noticed on x86_64 that the vmlinux.lds.S file that the _edata is
defined before .data.read_mostly and a few others. In this case, the
__read_mostly and cache aligned variables wouldn't be scanned. Could you
try the patch below?

diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 367e878..59f31d2 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -112,11 +112,6 @@ SECTIONS
 		_sdata = .;
 		DATA_DATA
 		CONSTRUCTORS
-
-#ifdef CONFIG_X86_64
-		/* End of data section */
-		_edata = .;
-#endif
 	} :data
 
 #ifdef CONFIG_X86_32
@@ -156,10 +151,8 @@ SECTIONS
 	.data.read_mostly : AT(ADDR(.data.read_mostly) - LOAD_OFFSET) {
 		*(.data.read_mostly)
 
-#ifdef CONFIG_X86_32
 		/* End of data section */
 		_edata = .;
-#endif
 	}
 
 #ifdef CONFIG_X86_64


Thanks.

-- 
Catalin

[PATCH] x86: _edata should include all .data.* sections on X86_64

[Catalin Marinas]

The .data.read_mostly and .data.cacheline_aligned sections aren't
covered by the _sdata .. _edata range on X86_64. This affects the
kmemleak reporting leading to possible false positives by not scanning
all the whole data section.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Ingo Molnar <mingo@elte.hu>
---

(I re-posted this patch with comments and cc'ing the relevant people)

 arch/x86/kernel/vmlinux.lds.S |    7 -------
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 367e878..59f31d2 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -112,11 +112,6 @@ SECTIONS
 		_sdata = .;
 		DATA_DATA
 		CONSTRUCTORS
-
-#ifdef CONFIG_X86_64
-		/* End of data section */
-		_edata = .;
-#endif
 	} :data
 
 #ifdef CONFIG_X86_32
@@ -156,10 +151,8 @@ SECTIONS
 	.data.read_mostly : AT(ADDR(.data.read_mostly) - LOAD_OFFSET) {
 		*(.data.read_mostly)
 
-#ifdef CONFIG_X86_32
 		/* End of data section */
 		_edata = .;
-#endif
 	}
 
 #ifdef CONFIG_X86_64

Re: [PATCH] x86: _edata should include all .data.* sections on X86_64

[Alexey Fisher]

With this patch i have only 25 reports....
but i still have a lot of ext4 and some other reports.


Catalin Marinas schrieb:
> The .data.read_mostly and .data.cacheline_aligned sections aren't
> covered by the _sdata .. _edata range on X86_64. This affects the
> kmemleak reporting leading to possible false positives by not scanning
> all the whole data section.
> 
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Ingo Molnar <mingo@elte.hu>
> ---
> 
> (I re-posted this patch with comments and cc'ing the relevant people)
> 
>  arch/x86/kernel/vmlinux.lds.S |    7 -------
>  1 files changed, 0 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
> index 367e878..59f31d2 100644
> --- a/arch/x86/kernel/vmlinux.lds.S
> +++ b/arch/x86/kernel/vmlinux.lds.S
> @@ -112,11 +112,6 @@ SECTIONS
>  		_sdata = .;
>  		DATA_DATA
>  		CONSTRUCTORS
> -
> -#ifdef CONFIG_X86_64
> -		/* End of data section */
> -		_edata = .;
> -#endif
>  	} :data
>  
>  #ifdef CONFIG_X86_32
> @@ -156,10 +151,8 @@ SECTIONS
>  	.data.read_mostly : AT(ADDR(.data.read_mostly) - LOAD_OFFSET) {
>  		*(.data.read_mostly)
>  
> -#ifdef CONFIG_X86_32
>  		/* End of data section */
>  		_edata = .;
> -#endif
>  	}
>  
>  #ifdef CONFIG_X86_64
> 

Re: [PATCH] x86: _edata should include all .data.* sections on X86_64

[Catalin Marinas]

On Tue, 2009-07-14 at 12:13 +0200, Alexey Fisher wrote:
> With this patch i have only 25 reports....
> but i still have a lot of ext4 and some other reports.

Apart from ext4, what are the other reports?

Thanks.

-- 
Catalin

Re: [PATCH] x86: _edata should include all .data.* sections on X86_64

[Alexey Fisher]

Catalin Marinas schrieb:
> On Tue, 2009-07-14 at 12:13 +0200, Alexey Fisher wrote:
>> With this patch i have only 25 reports....
>> but i still have a lot of ext4 and some other reports.
> 
> Apart from ext4, what are the other reports?
> 
> Thanks.
> 

this is complete trace from debug/kmemleak .
i will compile now latest linux-arm.org/linux-2.6.git

but i think i need step by step howto... it's really new for me.

unreferenced object 0xffff88013711c2a8 (size 64):
   comm "swapper", pid 1, jiffies 4294892383
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f596b>] __kmalloc+0x11b/0x210
     [<ffffffff81263b41>] kzalloc+0xf/0x11
     [<ffffffff8126416d>] acpi_add_single_object+0x5b0/0xd5a
     [<ffffffff81264b32>] acpi_bus_scan+0x125/0x1af
     [<ffffffff8176dcb7>] acpi_scan_init+0xc8/0xe9
     [<ffffffff8176da72>] acpi_init+0x21f/0x265
     [<ffffffff8100905b>] do_one_initcall+0x4b/0x190
     [<ffffffff8174b6ef>] kernel_init+0x169/0x1bf
     [<ffffffff8100c69a>] child_rip+0xa/0x20
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff8801349aa150 (size 96):
   comm "swapper", pid 1, jiffies 4294892492
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f4b8b>] kmem_cache_alloc+0xfb/0x180
     [<ffffffff811f815f>] new_inode_smack+0x2f/0xc0
     [<ffffffff811f8215>] smack_inode_alloc_security+0x25/0x40
     [<ffffffff811f0cdc>] security_inode_alloc+0x1c/0x20
     [<ffffffff811135a5>] inode_init_always+0xc5/0x220
     [<ffffffff8111372c>] alloc_inode+0x2c/0x50
     [<ffffffff81113778>] new_inode+0x28/0xc0
     [<ffffffff8111d581>] simple_fill_super+0x41/0x200
     [<ffffffff811f8da5>] smk_fill_super+0x25/0x70
     [<ffffffff81100ed8>] get_sb_single+0x98/0xc0
     [<ffffffff811f8d73>] smk_get_sb+0x13/0x20
     [<ffffffff81100bf6>] vfs_kern_mount+0x76/0x180
     [<ffffffff81100d14>] kern_mount_data+0x14/0x20
     [<ffffffff817677d0>] init_smk_fs+0x3b/0x7b
unreferenced object 0xffff880133bf8540 (size 96):
   comm "swapper", pid 1, jiffies 4294893530
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f596b>] __kmalloc+0x11b/0x210
     [<ffffffff8128b80c>] acpi_processor_register_performance+0x2ab/0x3eb
     [<ffffffff8101fc51>] acpi_cpufreq_cpu_init+0xb1/0x500
     [<ffffffff813b4004>] cpufreq_add_dev+0x154/0x650
     [<ffffffff81300926>] sysdev_driver_register+0xa6/0x130
     [<ffffffff813b3000>] cpufreq_register_driver+0x80/0x160
     [<ffffffff81754348>] acpi_cpufreq_init+0x91/0xc7
     [<ffffffff8100905b>] do_one_initcall+0x4b/0x190
     [<ffffffff8174b6ef>] kernel_init+0x169/0x1bf
     [<ffffffff8100c69a>] child_rip+0xa/0x20
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff880133bf85e8 (size 96):
   comm "swapper", pid 1, jiffies 4294893531
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f596b>] __kmalloc+0x11b/0x210
     [<ffffffff8128b80c>] acpi_processor_register_performance+0x2ab/0x3eb
     [<ffffffff8101fc51>] acpi_cpufreq_cpu_init+0xb1/0x500
     [<ffffffff813b4004>] cpufreq_add_dev+0x154/0x650
     [<ffffffff81300926>] sysdev_driver_register+0xa6/0x130
     [<ffffffff813b3000>] cpufreq_register_driver+0x80/0x160
     [<ffffffff81754348>] acpi_cpufreq_init+0x91/0xc7
     [<ffffffff8100905b>] do_one_initcall+0x4b/0x190
     [<ffffffff8174b6ef>] kernel_init+0x169/0x1bf
     [<ffffffff8100c69a>] child_rip+0xa/0x20
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff880132c48890 (size 1024):
   comm "exe", pid 1612, jiffies 4294894130
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f596b>] __kmalloc+0x11b/0x210
     [<ffffffff811ae061>] ext4_mb_init+0x1b1/0x5c0
     [<ffffffff8119f1e9>] ext4_fill_super+0x1e29/0x2720
     [<ffffffff8110111f>] get_sb_bdev+0x16f/0x1b0
     [<ffffffff81195413>] ext4_get_sb+0x13/0x20
     [<ffffffff81100bf6>] vfs_kern_mount+0x76/0x180
     [<ffffffff81100d6d>] do_kern_mount+0x4d/0x120
     [<ffffffff81118ee7>] do_mount+0x307/0x8b0
     [<ffffffff8111951f>] sys_mount+0x8f/0xe0
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff8801335be738 (size 192):
   comm "exe", pid 1612, jiffies 4294894130
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f596b>] __kmalloc+0x11b/0x210
     [<ffffffff811ae061>] ext4_mb_init+0x1b1/0x5c0
     [<ffffffff8119f1e9>] ext4_fill_super+0x1e29/0x2720
     [<ffffffff8110111f>] get_sb_bdev+0x16f/0x1b0
     [<ffffffff81195413>] ext4_get_sb+0x13/0x20
     [<ffffffff81100bf6>] vfs_kern_mount+0x76/0x180
     [<ffffffff81100d6d>] do_kern_mount+0x4d/0x120
     [<ffffffff81118ee7>] do_mount+0x307/0x8b0
     [<ffffffff8111951f>] sys_mount+0x8f/0xe0
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff8801329ac708 (size 128):
   comm "udevd", pid 1710, jiffies 4294894924
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f4b8b>] kmem_cache_alloc+0xfb/0x180
     [<ffffffff811325fa>] sys_inotify_add_watch+0xca/0x350
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff8801329ac7d0 (size 128):
   comm "udevd", pid 1710, jiffies 4294894924
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f4b8b>] kmem_cache_alloc+0xfb/0x180
     [<ffffffff811325fa>] sys_inotify_add_watch+0xca/0x350
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff8801329ac898 (size 128):
   comm "udevd", pid 1710, jiffies 4294894924
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f4b8b>] kmem_cache_alloc+0xfb/0x180
     [<ffffffff811325fa>] sys_inotify_add_watch+0xca/0x350
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff8801329ac960 (size 128):
   comm "udevd", pid 1710, jiffies 4294894924
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f4b8b>] kmem_cache_alloc+0xfb/0x180
     [<ffffffff811325fa>] sys_inotify_add_watch+0xca/0x350
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff8801329aca28 (size 128):
   comm "udevd", pid 1710, jiffies 4294894925
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f4b8b>] kmem_cache_alloc+0xfb/0x180
     [<ffffffff811325fa>] sys_inotify_add_watch+0xca/0x350
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff8801329acaf0 (size 128):
   comm "udevd", pid 1710, jiffies 4294894925
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f4b8b>] kmem_cache_alloc+0xfb/0x180
     [<ffffffff811325fa>] sys_inotify_add_watch+0xca/0x350
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff8801329acbb8 (size 128):
   comm "udevd", pid 1710, jiffies 4294894925
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f4b8b>] kmem_cache_alloc+0xfb/0x180
     [<ffffffff811325fa>] sys_inotify_add_watch+0xca/0x350
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff8801329ace10 (size 128):
   comm "udevd", pid 1710, jiffies 4294894925
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f4b8b>] kmem_cache_alloc+0xfb/0x180
     [<ffffffff811325fa>] sys_inotify_add_watch+0xca/0x350
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff88012f48d440 (size 64):
   comm "mount", pid 2393, jiffies 4294896562
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f596b>] __kmalloc+0x11b/0x210
     [<ffffffff811ae061>] ext4_mb_init+0x1b1/0x5c0
     [<ffffffff8119f1e9>] ext4_fill_super+0x1e29/0x2720
     [<ffffffff8110111f>] get_sb_bdev+0x16f/0x1b0
     [<ffffffff81195413>] ext4_get_sb+0x13/0x20
     [<ffffffff81100bf6>] vfs_kern_mount+0x76/0x180
     [<ffffffff81100d6d>] do_kern_mount+0x4d/0x120
     [<ffffffff81118ee7>] do_mount+0x307/0x8b0
     [<ffffffff8111951f>] sys_mount+0x8f/0xe0
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff880132815158 (size 1024):
   comm "mount", pid 2393, jiffies 4294896569
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f596b>] __kmalloc+0x11b/0x210
     [<ffffffff811ae061>] ext4_mb_init+0x1b1/0x5c0
     [<ffffffff8119f1e9>] ext4_fill_super+0x1e29/0x2720
     [<ffffffff8110111f>] get_sb_bdev+0x16f/0x1b0
     [<ffffffff81195413>] ext4_get_sb+0x13/0x20
     [<ffffffff81100bf6>] vfs_kern_mount+0x76/0x180
     [<ffffffff81100d6d>] do_kern_mount+0x4d/0x120
     [<ffffffff81118ee7>] do_mount+0x307/0x8b0
     [<ffffffff8111951f>] sys_mount+0x8f/0xe0
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff8801328159e8 (size 1024):
   comm "mount", pid 2393, jiffies 4294896569
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f596b>] __kmalloc+0x11b/0x210
     [<ffffffff811ae061>] ext4_mb_init+0x1b1/0x5c0
     [<ffffffff8119f1e9>] ext4_fill_super+0x1e29/0x2720
     [<ffffffff8110111f>] get_sb_bdev+0x16f/0x1b0
     [<ffffffff81195413>] ext4_get_sb+0x13/0x20
     [<ffffffff81100bf6>] vfs_kern_mount+0x76/0x180
     [<ffffffff81100d6d>] do_kern_mount+0x4d/0x120
     [<ffffffff81118ee7>] do_mount+0x307/0x8b0
     [<ffffffff8111951f>] sys_mount+0x8f/0xe0
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff880132816b08 (size 1024):
   comm "mount", pid 2393, jiffies 4294896569
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f596b>] __kmalloc+0x11b/0x210
     [<ffffffff811ae061>] ext4_mb_init+0x1b1/0x5c0
     [<ffffffff8119f1e9>] ext4_fill_super+0x1e29/0x2720
     [<ffffffff8110111f>] get_sb_bdev+0x16f/0x1b0
     [<ffffffff81195413>] ext4_get_sb+0x13/0x20
     [<ffffffff81100bf6>] vfs_kern_mount+0x76/0x180
     [<ffffffff81100d6d>] do_kern_mount+0x4d/0x120
     [<ffffffff81118ee7>] do_mount+0x307/0x8b0
     [<ffffffff8111951f>] sys_mount+0x8f/0xe0
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff8801328155a0 (size 1024):
   comm "mount", pid 2393, jiffies 4294896569
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f596b>] __kmalloc+0x11b/0x210
     [<ffffffff811ae061>] ext4_mb_init+0x1b1/0x5c0
     [<ffffffff8119f1e9>] ext4_fill_super+0x1e29/0x2720
     [<ffffffff8110111f>] get_sb_bdev+0x16f/0x1b0
     [<ffffffff81195413>] ext4_get_sb+0x13/0x20
     [<ffffffff81100bf6>] vfs_kern_mount+0x76/0x180
     [<ffffffff81100d6d>] do_kern_mount+0x4d/0x120
     [<ffffffff81118ee7>] do_mount+0x307/0x8b0
     [<ffffffff8111951f>] sys_mount+0x8f/0xe0
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff880132812f18 (size 1024):
   comm "mount", pid 2393, jiffies 4294896583
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f596b>] __kmalloc+0x11b/0x210
     [<ffffffff811ae061>] ext4_mb_init+0x1b1/0x5c0
     [<ffffffff8119f1e9>] ext4_fill_super+0x1e29/0x2720
     [<ffffffff8110111f>] get_sb_bdev+0x16f/0x1b0
     [<ffffffff81195413>] ext4_get_sb+0x13/0x20
     [<ffffffff81100bf6>] vfs_kern_mount+0x76/0x180
     [<ffffffff81100d6d>] do_kern_mount+0x4d/0x120
     [<ffffffff81118ee7>] do_mount+0x307/0x8b0
     [<ffffffff8111951f>] sys_mount+0x8f/0xe0
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff880132811568 (size 1024):
   comm "mount", pid 2393, jiffies 4294896583
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f596b>] __kmalloc+0x11b/0x210
     [<ffffffff811ae061>] ext4_mb_init+0x1b1/0x5c0
     [<ffffffff8119f1e9>] ext4_fill_super+0x1e29/0x2720
     [<ffffffff8110111f>] get_sb_bdev+0x16f/0x1b0
     [<ffffffff81195413>] ext4_get_sb+0x13/0x20
     [<ffffffff81100bf6>] vfs_kern_mount+0x76/0x180
     [<ffffffff81100d6d>] do_kern_mount+0x4d/0x120
     [<ffffffff81118ee7>] do_mount+0x307/0x8b0
     [<ffffffff8111951f>] sys_mount+0x8f/0xe0
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff880132811120 (size 1024):
   comm "mount", pid 2393, jiffies 4294896583
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f596b>] __kmalloc+0x11b/0x210
     [<ffffffff811ae061>] ext4_mb_init+0x1b1/0x5c0
     [<ffffffff8119f1e9>] ext4_fill_super+0x1e29/0x2720
     [<ffffffff8110111f>] get_sb_bdev+0x16f/0x1b0
     [<ffffffff81195413>] ext4_get_sb+0x13/0x20
     [<ffffffff81100bf6>] vfs_kern_mount+0x76/0x180
     [<ffffffff81100d6d>] do_kern_mount+0x4d/0x120
     [<ffffffff81118ee7>] do_mount+0x307/0x8b0
     [<ffffffff8111951f>] sys_mount+0x8f/0xe0
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff880132810cd8 (size 1024):
   comm "mount", pid 2393, jiffies 4294896583
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f596b>] __kmalloc+0x11b/0x210
     [<ffffffff811ae061>] ext4_mb_init+0x1b1/0x5c0
     [<ffffffff8119f1e9>] ext4_fill_super+0x1e29/0x2720
     [<ffffffff8110111f>] get_sb_bdev+0x16f/0x1b0
     [<ffffffff81195413>] ext4_get_sb+0x13/0x20
     [<ffffffff81100bf6>] vfs_kern_mount+0x76/0x180
     [<ffffffff81100d6d>] do_kern_mount+0x4d/0x120
     [<ffffffff81118ee7>] do_mount+0x307/0x8b0
     [<ffffffff8111951f>] sys_mount+0x8f/0xe0
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff880132810890 (size 1024):
   comm "mount", pid 2393, jiffies 4294896583
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f596b>] __kmalloc+0x11b/0x210
     [<ffffffff811ae061>] ext4_mb_init+0x1b1/0x5c0
     [<ffffffff8119f1e9>] ext4_fill_super+0x1e29/0x2720
     [<ffffffff8110111f>] get_sb_bdev+0x16f/0x1b0
     [<ffffffff81195413>] ext4_get_sb+0x13/0x20
     [<ffffffff81100bf6>] vfs_kern_mount+0x76/0x180
     [<ffffffff81100d6d>] do_kern_mount+0x4d/0x120
     [<ffffffff81118ee7>] do_mount+0x307/0x8b0
     [<ffffffff8111951f>] sys_mount+0x8f/0xe0
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff880132810448 (size 1024):
   comm "mount", pid 2393, jiffies 4294896583
   backtrace:
     [<ffffffff810fbaca>] create_object+0x13a/0x2c0
     [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f596b>] __kmalloc+0x11b/0x210
     [<ffffffff811ae061>] ext4_mb_init+0x1b1/0x5c0
     [<ffffffff8119f1e9>] ext4_fill_super+0x1e29/0x2720
     [<ffffffff8110111f>] get_sb_bdev+0x16f/0x1b0
     [<ffffffff81195413>] ext4_get_sb+0x13/0x20
     [<ffffffff81100bf6>] vfs_kern_mount+0x76/0x180
     [<ffffffff81100d6d>] do_kern_mount+0x4d/0x120
     [<ffffffff81118ee7>] do_mount+0x307/0x8b0
     [<ffffffff8111951f>] sys_mount+0x8f/0xe0
     [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
     [<ffffffffffffffff>] 0xffffffffffffffff

ext4 memory leak (was Re: [PATCH] x86: _edata should include all .data.* sections on X86_64)

[Catalin Marinas]

(I cc'ed linux-ext4@vger.kernel.org as well)

On Tue, 2009-07-14 at 12:37 +0200, Alexey Fisher wrote:
> this is complete trace from debug/kmemleak .
[...]
> i will compile now latest linux-arm.org/linux-2.6.git
> unreferenced object 0xffff880132c48890 (size 1024):
>    comm "exe", pid 1612, jiffies 4294894130
>    backtrace:
>      [<ffffffff810fbaca>] create_object+0x13a/0x2c0
>      [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
>      [<ffffffff810f596b>] __kmalloc+0x11b/0x210
>      [<ffffffff811ae061>] ext4_mb_init+0x1b1/0x5c0
>      [<ffffffff8119f1e9>] ext4_fill_super+0x1e29/0x2720
>      [<ffffffff8110111f>] get_sb_bdev+0x16f/0x1b0
>      [<ffffffff81195413>] ext4_get_sb+0x13/0x20
>      [<ffffffff81100bf6>] vfs_kern_mount+0x76/0x180
>      [<ffffffff81100d6d>] do_kern_mount+0x4d/0x120
>      [<ffffffff81118ee7>] do_mount+0x307/0x8b0
>      [<ffffffff8111951f>] sys_mount+0x8f/0xe0
>      [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
>      [<ffffffffffffffff>] 0xffffffffffffffff

After some investigation, this looks to me like a real leak.

I managed to reproduce something similar (though the size may differ, I
think depending on filesystem size - only tried with a 64MB loop
device):

unreferenced object 0xde468300 (size 32):
  comm "mount", pid 1445, jiffies 4294950074
  backtrace:
    [<c006d473>] __save_stack_trace+0x17/0x1c
    [<c006d545>] create_object+0xcd/0x188
    [<c01efe43>] kmemleak_alloc+0x1b/0x3c
    [<c006c013>] __kmalloc+0xd7/0xe4
    [<c00c1029>] ext4_mb_init+0x14d/0x374
    [<c00b7d7d>] ext4_fill_super+0x1385/0x16b4
    [<c0070891>] get_sb_bdev+0xa9/0xe4
    [<c00b574b>] ext4_get_sb+0xf/0x14
    [<c006fd3f>] vfs_kern_mount+0x33/0x64
    [<c006fda5>] do_kern_mount+0x25/0x8c
    [<c007e11f>] do_mount+0x47f/0x4c4
    [<c007e1b5>] sys_mount+0x51/0x80
    [<c0027c01>] ret_fast_syscall+0x1/0x40
    [<ffffffff>] 0xffffffff

The above block is the meta_group_info allocated in
ext4_mb_init_backend() and stored in sbi->s_group_info[i] (i = 0 in my
case). Adding printk's and and inspecting the memory at
sbi->s_group_info[] shows different value stored, not the pointer
reported as leak.

About the new pointer at sbi->s_group_info[0], kmemleak has this
information (via the dump= option in my branch; it isn't a leak report):

kmemleak: Object 0xdfebfa80 (size 128):
kmemleak:   comm "mount", pid 1445, jiffies 4294950075
kmemleak:   min_count = 1
kmemleak:   count = 1
kmemleak:   flags = 0x1
kmemleak:   backtrace:
     [<c006d473>] __save_stack_trace+0x17/0x1c
     [<c006d545>] create_object+0xcd/0x188
     [<c01efe43>] kmemleak_alloc+0x1b/0x3c
     [<c006c013>] __kmalloc+0xd7/0xe4
     [<c00c0df1>] ext4_mb_add_groupinfo+0x29/0x114
     [<c00c107f>] ext4_mb_init+0x1a3/0x374
     [<c00b7d7d>] ext4_fill_super+0x1385/0x16b4
     [<c0070891>] get_sb_bdev+0xa9/0xe4
     [<c00b574b>] ext4_get_sb+0xf/0x14
     [<c006fd3f>] vfs_kern_mount+0x33/0x64
     [<c006fda5>] do_kern_mount+0x25/0x8c
     [<c007e11f>] do_mount+0x47f/0x4c4
     [<c007e1b5>] sys_mount+0x51/0x80
     [<c0027c01>] ret_fast_syscall+0x1/0x40
     [<ffffffff>] 0xffffffff

So, ext4_mb_add_groupinfo() is overriding the pointers stored in
sbi->s_group_info[] by the ext4_mb_init_backend() function without
freeing them first.

Maybe the ext4 people could clarify what is happening here as I'm not
familiar with the code.

-- 
Catalin

Re: ext4 memory leak (was Re: [PATCH] x86: _edata should include all .data.* sections on X86_64)

[Aneesh Kumar K.V]

On Tue, Jul 14, 2009 at 01:26:30PM +0100, Catalin Marinas wrote:
> (I cc'ed linux-ext4@vger.kernel.org as well)
> 
> On Tue, 2009-07-14 at 12:37 +0200, Alexey Fisher wrote:
> > this is complete trace from debug/kmemleak .
> [...]
> > i will compile now latest linux-arm.org/linux-2.6.git
> > unreferenced object 0xffff880132c48890 (size 1024):
> >    comm "exe", pid 1612, jiffies 4294894130
> >    backtrace:
> >      [<ffffffff810fbaca>] create_object+0x13a/0x2c0
> >      [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
> >      [<ffffffff810f596b>] __kmalloc+0x11b/0x210
> >      [<ffffffff811ae061>] ext4_mb_init+0x1b1/0x5c0
> >      [<ffffffff8119f1e9>] ext4_fill_super+0x1e29/0x2720
> >      [<ffffffff8110111f>] get_sb_bdev+0x16f/0x1b0
> >      [<ffffffff81195413>] ext4_get_sb+0x13/0x20
> >      [<ffffffff81100bf6>] vfs_kern_mount+0x76/0x180
> >      [<ffffffff81100d6d>] do_kern_mount+0x4d/0x120
> >      [<ffffffff81118ee7>] do_mount+0x307/0x8b0
> >      [<ffffffff8111951f>] sys_mount+0x8f/0xe0
> >      [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
> >      [<ffffffffffffffff>] 0xffffffffffffffff
> 
> After some investigation, this looks to me like a real leak.
> 
> I managed to reproduce something similar (though the size may differ, I
> think depending on filesystem size - only tried with a 64MB loop
> device):
> 
> unreferenced object 0xde468300 (size 32):
>   comm "mount", pid 1445, jiffies 4294950074
>   backtrace:
>     [<c006d473>] __save_stack_trace+0x17/0x1c
>     [<c006d545>] create_object+0xcd/0x188
>     [<c01efe43>] kmemleak_alloc+0x1b/0x3c
>     [<c006c013>] __kmalloc+0xd7/0xe4
>     [<c00c1029>] ext4_mb_init+0x14d/0x374
>     [<c00b7d7d>] ext4_fill_super+0x1385/0x16b4
>     [<c0070891>] get_sb_bdev+0xa9/0xe4
>     [<c00b574b>] ext4_get_sb+0xf/0x14
>     [<c006fd3f>] vfs_kern_mount+0x33/0x64
>     [<c006fda5>] do_kern_mount+0x25/0x8c
>     [<c007e11f>] do_mount+0x47f/0x4c4
>     [<c007e1b5>] sys_mount+0x51/0x80
>     [<c0027c01>] ret_fast_syscall+0x1/0x40
>     [<ffffffff>] 0xffffffff
> 
> The above block is the meta_group_info allocated in
> ext4_mb_init_backend() and stored in sbi->s_group_info[i] (i = 0 in my
> case). Adding printk's and and inspecting the memory at
> sbi->s_group_info[] shows different value stored, not the pointer
> reported as leak.
> 
> About the new pointer at sbi->s_group_info[0], kmemleak has this
> information (via the dump= option in my branch; it isn't a leak report):
> 
> kmemleak: Object 0xdfebfa80 (size 128):
> kmemleak:   comm "mount", pid 1445, jiffies 4294950075
> kmemleak:   min_count = 1
> kmemleak:   count = 1
> kmemleak:   flags = 0x1
> kmemleak:   backtrace:
>      [<c006d473>] __save_stack_trace+0x17/0x1c
>      [<c006d545>] create_object+0xcd/0x188
>      [<c01efe43>] kmemleak_alloc+0x1b/0x3c
>      [<c006c013>] __kmalloc+0xd7/0xe4
>      [<c00c0df1>] ext4_mb_add_groupinfo+0x29/0x114
>      [<c00c107f>] ext4_mb_init+0x1a3/0x374
>      [<c00b7d7d>] ext4_fill_super+0x1385/0x16b4
>      [<c0070891>] get_sb_bdev+0xa9/0xe4
>      [<c00b574b>] ext4_get_sb+0xf/0x14
>      [<c006fd3f>] vfs_kern_mount+0x33/0x64
>      [<c006fda5>] do_kern_mount+0x25/0x8c
>      [<c007e11f>] do_mount+0x47f/0x4c4
>      [<c007e1b5>] sys_mount+0x51/0x80
>      [<c0027c01>] ret_fast_syscall+0x1/0x40
>      [<ffffffff>] 0xffffffff
> 
> So, ext4_mb_add_groupinfo() is overriding the pointers stored in
> sbi->s_group_info[] by the ext4_mb_init_backend() function without
> freeing them first.
> 
> Maybe the ext4 people could clarify what is happening here as I'm not
> familiar with the code.
> 

Can you try this patch ?

commit 4cc505d4c16c86f8f590ce4b288c920572bf2be9
Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Date:   Wed Jul 15 13:20:37 2009 +0530

    ext4: Memory leak fix ext4_group_info allocation.
    
    commit 5f21b0e642d7bf6fe4434c9ba12bc9cb96b17cf7  was done to
    reallocate groupinfo struct during resize properly. That goal
    was to allocate new groupinfo struct when we are adding new block
    groups during resize. Calling ext4_mb_add_group_info in the
    mballoc initialization code path resulted in we reallocating
    the group info struct . Fix this by not separately allocating
    group info in the mballoc init path and always depend on
    ext4_mb_add_group_info to allocate group info struct.
    
    The earlier code also had a bug that we allocated less number of
    group info struct for the last meta group. But on resize we
    expected that we had EXT4_DESC_PER_BLOCK group info struct for
    each meta group.
    
    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>

diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index 519a0a6..96ed1d8 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -2615,22 +2615,6 @@ static int ext4_mb_init_backend(struct super_block *sb)
 		goto err_freesgi;
 	}
 	EXT4_I(sbi->s_buddy_cache)->i_disksize = 0;
-
-	metalen = sizeof(*meta_group_info) << EXT4_DESC_PER_BLOCK_BITS(sb);
-	for (i = 0; i < num_meta_group_infos; i++) {
-		if ((i + 1) == num_meta_group_infos)
-			metalen = sizeof(*meta_group_info) *
-				(ngroups -
-					(i << EXT4_DESC_PER_BLOCK_BITS(sb)));
-		meta_group_info = kmalloc(metalen, GFP_KERNEL);
-		if (meta_group_info == NULL) {
-			printk(KERN_ERR "EXT4-fs: can't allocate mem for a "
-			       "buddy group\n");
-			goto err_freemeta;
-		}
-		sbi->s_group_info[i] = meta_group_info;
-	}
-
 	for (i = 0; i < ngroups; i++) {
 		desc = ext4_get_group_desc(sb, i, NULL);
 		if (desc == NULL) {

Re: ext4 memory leak (was Re: [PATCH] x86: _edata should include all .data.* sections on X86_64)

[Alexey Fisher]

This patch work for me.

Aneesh Kumar K.V schrieb:
> On Tue, Jul 14, 2009 at 01:26:30PM +0100, Catalin Marinas wrote:
>> (I cc'ed linux-ext4@vger.kernel.org as well)
>>
>> On Tue, 2009-07-14 at 12:37 +0200, Alexey Fisher wrote:
>>> this is complete trace from debug/kmemleak .
>> [...]
>>> i will compile now latest linux-arm.org/linux-2.6.git
>>> unreferenced object 0xffff880132c48890 (size 1024):
>>>    comm "exe", pid 1612, jiffies 4294894130
>>>    backtrace:
>>>      [<ffffffff810fbaca>] create_object+0x13a/0x2c0
>>>      [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
>>>      [<ffffffff810f596b>] __kmalloc+0x11b/0x210
>>>      [<ffffffff811ae061>] ext4_mb_init+0x1b1/0x5c0
>>>      [<ffffffff8119f1e9>] ext4_fill_super+0x1e29/0x2720
>>>      [<ffffffff8110111f>] get_sb_bdev+0x16f/0x1b0
>>>      [<ffffffff81195413>] ext4_get_sb+0x13/0x20
>>>      [<ffffffff81100bf6>] vfs_kern_mount+0x76/0x180
>>>      [<ffffffff81100d6d>] do_kern_mount+0x4d/0x120
>>>      [<ffffffff81118ee7>] do_mount+0x307/0x8b0
>>>      [<ffffffff8111951f>] sys_mount+0x8f/0xe0
>>>      [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
>>>      [<ffffffffffffffff>] 0xffffffffffffffff
>> After some investigation, this looks to me like a real leak.
>>
>> I managed to reproduce something similar (though the size may differ, I
>> think depending on filesystem size - only tried with a 64MB loop
>> device):
>>
>> unreferenced object 0xde468300 (size 32):
>>   comm "mount", pid 1445, jiffies 4294950074
>>   backtrace:
>>     [<c006d473>] __save_stack_trace+0x17/0x1c
>>     [<c006d545>] create_object+0xcd/0x188
>>     [<c01efe43>] kmemleak_alloc+0x1b/0x3c
>>     [<c006c013>] __kmalloc+0xd7/0xe4
>>     [<c00c1029>] ext4_mb_init+0x14d/0x374
>>     [<c00b7d7d>] ext4_fill_super+0x1385/0x16b4
>>     [<c0070891>] get_sb_bdev+0xa9/0xe4
>>     [<c00b574b>] ext4_get_sb+0xf/0x14
>>     [<c006fd3f>] vfs_kern_mount+0x33/0x64
>>     [<c006fda5>] do_kern_mount+0x25/0x8c
>>     [<c007e11f>] do_mount+0x47f/0x4c4
>>     [<c007e1b5>] sys_mount+0x51/0x80
>>     [<c0027c01>] ret_fast_syscall+0x1/0x40
>>     [<ffffffff>] 0xffffffff
>>
>> The above block is the meta_group_info allocated in
>> ext4_mb_init_backend() and stored in sbi->s_group_info[i] (i = 0 in my
>> case). Adding printk's and and inspecting the memory at
>> sbi->s_group_info[] shows different value stored, not the pointer
>> reported as leak.
>>
>> About the new pointer at sbi->s_group_info[0], kmemleak has this
>> information (via the dump= option in my branch; it isn't a leak report):
>>
>> kmemleak: Object 0xdfebfa80 (size 128):
>> kmemleak:   comm "mount", pid 1445, jiffies 4294950075
>> kmemleak:   min_count = 1
>> kmemleak:   count = 1
>> kmemleak:   flags = 0x1
>> kmemleak:   backtrace:
>>      [<c006d473>] __save_stack_trace+0x17/0x1c
>>      [<c006d545>] create_object+0xcd/0x188
>>      [<c01efe43>] kmemleak_alloc+0x1b/0x3c
>>      [<c006c013>] __kmalloc+0xd7/0xe4
>>      [<c00c0df1>] ext4_mb_add_groupinfo+0x29/0x114
>>      [<c00c107f>] ext4_mb_init+0x1a3/0x374
>>      [<c00b7d7d>] ext4_fill_super+0x1385/0x16b4
>>      [<c0070891>] get_sb_bdev+0xa9/0xe4
>>      [<c00b574b>] ext4_get_sb+0xf/0x14
>>      [<c006fd3f>] vfs_kern_mount+0x33/0x64
>>      [<c006fda5>] do_kern_mount+0x25/0x8c
>>      [<c007e11f>] do_mount+0x47f/0x4c4
>>      [<c007e1b5>] sys_mount+0x51/0x80
>>      [<c0027c01>] ret_fast_syscall+0x1/0x40
>>      [<ffffffff>] 0xffffffff
>>
>> So, ext4_mb_add_groupinfo() is overriding the pointers stored in
>> sbi->s_group_info[] by the ext4_mb_init_backend() function without
>> freeing them first.
>>
>> Maybe the ext4 people could clarify what is happening here as I'm not
>> familiar with the code.
>>
> 
> Can you try this patch ?
> 
> commit 4cc505d4c16c86f8f590ce4b288c920572bf2be9
> Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> Date:   Wed Jul 15 13:20:37 2009 +0530
> 
>     ext4: Memory leak fix ext4_group_info allocation.
>     
>     commit 5f21b0e642d7bf6fe4434c9ba12bc9cb96b17cf7  was done to
>     reallocate groupinfo struct during resize properly. That goal
>     was to allocate new groupinfo struct when we are adding new block
>     groups during resize. Calling ext4_mb_add_group_info in the
>     mballoc initialization code path resulted in we reallocating
>     the group info struct . Fix this by not separately allocating
>     group info in the mballoc init path and always depend on
>     ext4_mb_add_group_info to allocate group info struct.
>     
>     The earlier code also had a bug that we allocated less number of
>     group info struct for the last meta group. But on resize we
>     expected that we had EXT4_DESC_PER_BLOCK group info struct for
>     each meta group.
>     
>     Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> 
> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index 519a0a6..96ed1d8 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -2615,22 +2615,6 @@ static int ext4_mb_init_backend(struct super_block *sb)
>  		goto err_freesgi;
>  	}
>  	EXT4_I(sbi->s_buddy_cache)->i_disksize = 0;
> -
> -	metalen = sizeof(*meta_group_info) << EXT4_DESC_PER_BLOCK_BITS(sb);
> -	for (i = 0; i < num_meta_group_infos; i++) {
> -		if ((i + 1) == num_meta_group_infos)
> -			metalen = sizeof(*meta_group_info) *
> -				(ngroups -
> -					(i << EXT4_DESC_PER_BLOCK_BITS(sb)));
> -		meta_group_info = kmalloc(metalen, GFP_KERNEL);
> -		if (meta_group_info == NULL) {
> -			printk(KERN_ERR "EXT4-fs: can't allocate mem for a "
> -			       "buddy group\n");
> -			goto err_freemeta;
> -		}
> -		sbi->s_group_info[i] = meta_group_info;
> -	}
> -
>  	for (i = 0; i < ngroups; i++) {
>  		desc = ext4_get_group_desc(sb, i, NULL);
>  		if (desc == NULL) {
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-testers" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ext4 memory leak (was Re: [PATCH] x86: _edata should include all .data.* sections on X86_64)

[Ingo Molnar]

* Alexey Fisher <bug-track@fisher-privat.net> wrote:

> This patch work for me.

nice. Any leftovers that might be false positives and need 
annotation?

We learned this with lockdep: the moment a typical x86 distro bootup 
is 'warnings free', utility of the debugging facility increases 
dramatically: people can standardize on 'kmemleak should never 
produce warnings' workflows and distros can also start feeding 
kmemleak reports into kerneloops.org or so.

So the general direction kmemleak is moving into is really 
encouraging.

	Ingo

Re: ext4 memory leak (was Re: [PATCH] x86: _edata should include all .data.* sections on X86_64)

[Alexey Fisher]

Ingo Molnar schrieb:
> * Alexey Fisher <bug-track@fisher-privat.net> wrote:
> 
>> This patch work for me.
> 
> nice. Any leftovers that might be false positives and need 
> annotation?
> 
> We learned this with lockdep: the moment a typical x86 distro bootup 
> is 'warnings free', utility of the debugging facility increases 
> dramatically: people can standardize on 'kmemleak should never 
> produce warnings' workflows and distros can also start feeding 
> kmemleak reports into kerneloops.org or so.
> 
> So the general direction kmemleak is moving into is really 
> encouraging.
> 
> 	Ingo

suddenly my kernel is not warning free... i have still warning about 
acpi_init, cpufreg, intel_gem and inoitfy on my PC and about firmware 
loader on my laptop. So i think there is still some job to do. I will 
report this warnings soon.

Re: ext4 memory leak (was Re: [PATCH] x86: _edata should include all .data.* sections on X86_64)

[Catalin Marinas]

On Sat, 2009-07-18 at 15:30 +0200, Alexey Fisher wrote:
> suddenly my kernel is not warning free... i have still warning about 
> acpi_init, cpufreg, intel_gem and inoitfy on my PC and about firmware 
> loader on my laptop. So i think there is still some job to do. I will 
> report this warnings soon.

Mine is not warning free either but they look like real leaks. There are
also a few more leaks reported by Jaswinder.

The inotify one was fixed but not in mainline yet (a fix was included in
my kmemleak-fixes branch).

What I get consistently:

unreferenced object 0xf72a9a80 (size 64):
  comm "swapper", pid 1, jiffies 4294892557
  hex dump (first 32 bytes):
    00 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00  ....8...........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<c056aa8d>] kmemleak_alloc+0x3d/0x70
    [<c01e234d>] __kmalloc+0x10d/0x210
    [<c0351122>] kzalloc+0xb/0xd
    [<c0351798>] acpi_add_single_object+0x609/0xe65
    [<c03521c6>] acpi_bus_scan+0xfd/0x174
    [<c07c1629>] acpi_scan_init+0xb5/0xd5
    [<c07c140b>] acpi_init+0x21e/0x262
    [<c010112b>] do_one_initcall+0x2b/0x160
    [<c0799355>] kernel_init+0x150/0x1aa
    [<c0103e57>] kernel_thread_helper+0x7/0x10
    [<ffffffff>] 0xffffffff

Every time I kill the X server (reported here -
http://lkml.org/lkml/2009/7/8/422)

unreferenced object 0xcb5a6600 (size 44):
  comm "gdm", pid 5246, jiffies 4960
  hex dump (first 32 bytes):
    02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 e4 b5 2d ca 90 4e 15 c0 83 14 00 00  ......-..N......
  backtrace:
    [<c056aa8d>] kmemleak_alloc+0x3d/0x70
    [<c01e0be6>] kmem_cache_alloc+0x156/0x1a0
    [<c01552f9>] alloc_pid+0x19/0x350
    [<c013e6f0>] copy_process+0x800/0x1230
    [<c013f18f>] do_fork+0x6f/0x370
    [<c0101986>] sys_clone+0x36/0x40
    [<c010319c>] sysenter_do_call+0x12/0x38
    [<ffffffff>] 0xffffffff

And quite a lot of these (also reported here -
http://lkml.org/lkml/2009/7/9/110 - but the first one was fixed by
Jaswinder and included in my kmemleak-fixes branch):

unreferenced object 0xcb0166c0 (size 148):
  comm "Xorg", pid 5251, jiffies 5784
  hex dump (first 32 bytes):
    ff ff ff ff 30 7f 98 c3 00 80 18 cb 90 80 18 cb  ....0...........
    20 81 18 cb b0 81 18 cb 40 82 18 cb d0 82 18 cb   .......@.......
  backtrace:
    [<c056aa8d>] kmemleak_alloc+0x3d/0x70
    [<c01e0be6>] kmem_cache_alloc+0x156/0x1a0
    [<c0317bf0>] idr_pre_get+0x50/0x70
    [<fa448ff4>] drm_gem_handle_create+0x24/0x90 [drm]
    [<fa8b34ad>] i915_gem_create_ioctl+0x5d/0xb0 [i915]
    [<fa4477c2>] drm_ioctl+0x192/0x3a0 [drm]
    [<c01f8339>] vfs_ioctl+0x79/0x90
    [<c01f849a>] do_vfs_ioctl+0x6a/0x5e0
    [<c01f8a73>] sys_ioctl+0x63/0x70
    [<c010319c>] sysenter_do_call+0x12/0x38
    [<ffffffff>] 0xffffffff

-- 
Catalin

Re: ext4 memory leak (was Re: [PATCH] x86: _edata should include all .data.* sections on X86_64)

[Catalin Marinas]

On Sat, 2009-07-18 at 13:55 +0200, Ingo Molnar wrote:
> * Alexey Fisher <bug-track@fisher-privat.net> wrote:
> 
> > This patch work for me.
> 
> nice. Any leftovers that might be false positives and need 
> annotation?

With the latest mainline all the reports I get look like real leaks but
some of them are pretty difficult to debug. I have a kmemleak
development tree as well which, among other things like more
cond_resched() calls, scans all the task stacks (currently using
for_each_process) but it doesn't reduce the number of reports.

> We learned this with lockdep: the moment a typical x86 distro bootup 
> is 'warnings free', utility of the debugging facility increases 
> dramatically: people can standardize on 'kmemleak should never 
> produce warnings' workflows and distros can also start feeding 
> kmemleak reports into kerneloops.org or so.

Yes. It's also easy to identify recent commits causing leaks but
currently it looks like some of the have been around for some time
(though probably not so serious leaks).

-- 
Catalin

Re: ext4 memory leak (was Re: [PATCH] x86: _edata should include all .data.* sections on X86_64)

[Catalin Marinas]

On Wed, 2009-07-15 at 13:33 +0530, Aneesh Kumar K.V wrote:
> Can you try this patch ?
[...]
>     ext4: Memory leak fix ext4_group_info allocation.
>     
>     commit 5f21b0e642d7bf6fe4434c9ba12bc9cb96b17cf7  was done to
>     reallocate groupinfo struct during resize properly. That goal
>     was to allocate new groupinfo struct when we are adding new block
>     groups during resize. Calling ext4_mb_add_group_info in the
>     mballoc initialization code path resulted in we reallocating
>     the group info struct . Fix this by not separately allocating
>     group info in the mballoc init path and always depend on
>     ext4_mb_add_group_info to allocate group info struct.
>     
>     The earlier code also had a bug that we allocated less number of
>     group info struct for the last meta group. But on resize we
>     expected that we had EXT4_DESC_PER_BLOCK group info struct for
>     each meta group.
>     
>     Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>

The kmemleak report disappeared.

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

BTW, there are a few compiler warnings about unused variables with this
patch.

-- 
Catalin

Re: [PATCH] x86: _edata should include all .data.* sections on X86_64

[Catalin Marinas]

On Tue, 2009-07-14 at 12:37 +0200, Alexey Fisher wrote:
> this is complete trace from debug/kmemleak .
> i will compile now latest linux-arm.org/linux-2.6.git
> 
> but i think i need step by step howto... it's really new for me.

>From my experience, debugging the memory leaks is very time consuming.
Kmemleak just reports what it thinks are leaks and where they were
allocated but not where they should be freed. With the recent patches,
persistent kmemleak false positives dropped to nearly 0 (you may get a
few transient reports but subsequent scans should eliminate them).

Apart from the ext4 leak, there are some comments below:

> unreferenced object 0xffff88013711c2a8 (size 64):
>    comm "swapper", pid 1, jiffies 4294892383
>    backtrace:
>      [<ffffffff810fbaca>] create_object+0x13a/0x2c0
>      [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
>      [<ffffffff810f596b>] __kmalloc+0x11b/0x210
>      [<ffffffff81263b41>] kzalloc+0xf/0x11
>      [<ffffffff8126416d>] acpi_add_single_object+0x5b0/0xd5a
>      [<ffffffff81264b32>] acpi_bus_scan+0x125/0x1af
>      [<ffffffff8176dcb7>] acpi_scan_init+0xc8/0xe9
>      [<ffffffff8176da72>] acpi_init+0x21f/0x265
>      [<ffffffff8100905b>] do_one_initcall+0x4b/0x190
>      [<ffffffff8174b6ef>] kernel_init+0x169/0x1bf
>      [<ffffffff8100c69a>] child_rip+0xa/0x20
>      [<ffffffffffffffff>] 0xffffffffffffffff

I get ACPI reports as well and it's possible they are real leaks but the
code is too complex to debug.

> unreferenced object 0xffff8801329ac708 (size 128):
>    comm "udevd", pid 1710, jiffies 4294894924
>    backtrace:
>      [<ffffffff810fbaca>] create_object+0x13a/0x2c0
>      [<ffffffff810fbd75>] kmemleak_alloc+0x25/0x60
>      [<ffffffff810f4b8b>] kmem_cache_alloc+0xfb/0x180
>      [<ffffffff811325fa>] sys_inotify_add_watch+0xca/0x350
>      [<ffffffff8100b66b>] system_call_fastpath+0x16/0x1b
>      [<ffffffffffffffff>] 0xffffffffffffffff

Real leak - reported here http://lkml.org/lkml/2009/7/6/334 and a patch
should be merged into mainline at some point.

-- 
Catalin

Re: [PATCH] x86: _edata should include all .data.* sections on X86_64

[Sam Ravnborg]

On Tue, Jul 14, 2009 at 10:52:55AM +0100, Catalin Marinas wrote:
> The .data.read_mostly and .data.cacheline_aligned sections aren't
> covered by the _sdata .. _edata range on X86_64. This affects the
> kmemleak reporting leading to possible false positives by not scanning
> all the whole data section.
> 
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Ingo Molnar <mingo@elte.hu>
> ---

To do so was on my todo list when I looked at vmlinux.lds.S for x86, but
as I got sidetracked I never got to it. Which I see was bad..
This patch has my:

Acked-by: Sam Ravnborg <sam@ravnborg.org>

	Sam

[tip:x86/urgent] x86: Include all of .data.* sections in _edata on 64-bit

[tip-bot for Catalin Marinas]

Commit-ID:  8bcdbe427924a1e4b4e4cf68020e92e9f93fe011
Gitweb:     http://git.kernel.org/tip/8bcdbe427924a1e4b4e4cf68020e92e9f93fe011
Author:     Catalin Marinas <catalin.marinas@arm.com>
AuthorDate: Tue, 14 Jul 2009 10:52:55 +0100
Committer:  Ingo Molnar <mingo@elte.hu>
CommitDate: Sat, 18 Jul 2009 13:59:20 +0200

x86: Include all of .data.* sections in _edata on 64-bit

The .data.read_mostly and .data.cacheline_aligned sections
aren't covered by the _sdata .. _edata range on x86-64. This
affects kmemleak reporting leading to possible false
positives by not scanning the whole data section.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Alexey Fisher <bug-track@fisher-privat.net>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>
LKML-Reference: <1247565175.28240.37.camel@pc1117.cambridge.arm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Sam Ravnborg <sam@ravnborg.org>


---
 arch/x86/kernel/vmlinux.lds.S |    7 -------
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 367e878..59f31d2 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -112,11 +112,6 @@ SECTIONS
 		_sdata = .;
 		DATA_DATA
 		CONSTRUCTORS
-
-#ifdef CONFIG_X86_64
-		/* End of data section */
-		_edata = .;
-#endif
 	} :data
 
 #ifdef CONFIG_X86_32
@@ -156,10 +151,8 @@ SECTIONS
 	.data.read_mostly : AT(ADDR(.data.read_mostly) - LOAD_OFFSET) {
 		*(.data.read_mostly)
 
-#ifdef CONFIG_X86_32
 		/* End of data section */
 		_edata = .;
-#endif
 	}
 
 #ifdef CONFIG_X86_64

[kmemleak] 60 wornings on sysfs_new_dirent+0x10c

[Alexey Fisher]

I getting a lot of sysfs_new_dirent warnings with latest ARM git.
this message come if my usb-cardreader is attached.


this are first sysfs_new_dirent warnings:
======================================================
unreferenced object 0xffff880133c580a0 (size 8):
   comm "khubd", pid 218, jiffies 4294893605
   hex dump (first 8 bytes):
     31 2d 36 00 01 88 ff ff                          1-6.....
   backtrace:
     [<ffffffff814a3115>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f36ab>] __kmalloc_track_caller+0x10b/0x200
     [<ffffffff810d4480>] kstrdup+0x40/0x70
     [<ffffffff8115ebdc>] sysfs_new_dirent+0x10c/0x120
     [<ffffffff8115f9fd>] create_dir+0x3d/0xb0
     [<ffffffff8115faa4>] sysfs_create_dir+0x34/0x50
     [<ffffffff8121ea37>] kobject_add_internal+0xb7/0x200
     [<ffffffff8121eca8>] kobject_add_varg+0x38/0x60
     [<ffffffff8121ed84>] kobject_add+0x44/0x70
     [<ffffffff812f8408>] device_add+0x118/0x5d0
     [<ffffffff8134914d>] usb_new_device+0x6d/0xe0
     [<ffffffff8134adf8>] hub_thread+0x878/0x1280
     [<ffffffff810644f6>] kthread+0x96/0xa0
     [<ffffffff8100c69a>] child_rip+0xa/0x20
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff880133c653c0 (size 80):
   comm "khubd", pid 218, jiffies 4294893605
   hex dump (first 32 bytes):
     01 00 00 00 00 00 00 80 10 2e 1c 34 01 88 ff ff  ...........4....
     00 00 00 00 00 00 00 00 a0 80 c5 33 01 88 ff ff  ...........3....
   backtrace:
     [<ffffffff814a3115>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f2aeb>] kmem_cache_alloc+0xfb/0x180
     [<ffffffff8115eb0c>] sysfs_new_dirent+0x3c/0x120
     [<ffffffff8115f9fd>] create_dir+0x3d/0xb0
     [<ffffffff8115faa4>] sysfs_create_dir+0x34/0x50
     [<ffffffff8121ea37>] kobject_add_internal+0xb7/0x200
     [<ffffffff8121eca8>] kobject_add_varg+0x38/0x60
     [<ffffffff8121ed84>] kobject_add+0x44/0x70
     [<ffffffff812f8408>] device_add+0x118/0x5d0
     [<ffffffff8134914d>] usb_new_device+0x6d/0xe0
     [<ffffffff8134adf8>] hub_thread+0x878/0x1280
     [<ffffffff810644f6>] kthread+0x96/0xa0
     [<ffffffff8100c69a>] child_rip+0xa/0x20
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff880133c580e8 (size 8):
   comm "khubd", pid 218, jiffies 4294893605
   hex dump (first 8 bytes):
     31 2d 36 3a 31 2e 30 00                          1-6:1.0.
   backtrace:
     [<ffffffff814a3115>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f36ab>] __kmalloc_track_caller+0x10b/0x200
     [<ffffffff810d4480>] kstrdup+0x40/0x70
     [<ffffffff8115ebdc>] sysfs_new_dirent+0x10c/0x120
     [<ffffffff8115f9fd>] create_dir+0x3d/0xb0
     [<ffffffff8115faa4>] sysfs_create_dir+0x34/0x50
     [<ffffffff8121ea37>] kobject_add_internal+0xb7/0x200
     [<ffffffff8121eca8>] kobject_add_varg+0x38/0x60
     [<ffffffff8121ed84>] kobject_add+0x44/0x70
     [<ffffffff812f8408>] device_add+0x118/0x5d0
     [<ffffffff81351054>] usb_set_configuration+0x444/0x740
     [<ffffffff8135aba2>] generic_probe+0x32/0xb0
     [<ffffffff81351425>] usb_probe_device+0x25/0x30
     [<ffffffff812faec6>] driver_probe_device+0x86/0x180
     [<ffffffff812fb0ab>] __device_attach+0x4b/0x50
     [<ffffffff812fa048>] bus_for_each_drv+0x68/0x90
unreferenced object 0xffff880133cf2b40 (size 80):
   comm "khubd", pid 218, jiffies 4294893605
   hex dump (first 32 bytes):
     01 00 00 00 00 00 00 80 c0 53 c6 33 01 88 ff ff  .........S.3....
     00 00 00 00 00 00 00 00 e8 80 c5 33 01 88 ff ff  ...........3....
   backtrace:
     [<ffffffff814a3115>] kmemleak_alloc+0x25/0x60
     [<ffffffff810f2aeb>] kmem_cache_alloc+0xfb/0x180
     [<ffffffff8115eb0c>] sysfs_new_dirent+0x3c/0x120
     [<ffffffff8115f9fd>] create_dir+0x3d/0xb0
     [<ffffffff8115faa4>] sysfs_create_dir+0x34/0x50
     [<ffffffff8121ea37>] kobject_add_internal+0xb7/0x200
     [<ffffffff8121eca8>] kobject_add_varg+0x38/0x60
     [<ffffffff8121ed84>] kobject_add+0x44/0x70
     [<ffffffff812f8408>] device_add+0x118/0x5d0
     [<ffffffff81351054>] usb_set_configuration+0x444/0x740
     [<ffffffff8135aba2>] generic_probe+0x32/0xb0
     [<ffffffff81351425>] usb_probe_device+0x25/0x30
     [<ffffffff812faec6>] driver_probe_device+0x86/0x180
     [<ffffffff812fb0ab>] __device_attach+0x4b/0x50
     [<ffffffff812fa048>] bus_for_each_drv+0x68/0x90
     [<ffffffff812fb166>] device_attach+0x86/0x90
===================================================================


dump:
==================================================================
[  604.393175] kmemleak: Object 0xffff880133c580a0 (size 8):
[  604.393179] kmemleak:   comm "khubd", pid 218, jiffies 4294893605
[  604.393180] kmemleak:   min_count = 1
[  604.393182] kmemleak:   count = 0
[  604.393183] kmemleak:   flags = 0x3
[  604.393184] kmemleak:   backtrace:
[  604.393186]      [<ffffffff814a3115>] kmemleak_alloc+0x25/0x60
[  604.393193]      [<ffffffff810f36ab>] __kmalloc_track_caller+0x10b/0x200
[  604.393198]      [<ffffffff810d4480>] kstrdup+0x40/0x70
[  604.393201]      [<ffffffff8115ebdc>] sysfs_new_dirent+0x10c/0x120
[  604.393206]      [<ffffffff8115f9fd>] create_dir+0x3d/0xb0
[  604.393209]      [<ffffffff8115faa4>] sysfs_create_dir+0x34/0x50
[  604.393212]      [<ffffffff8121ea37>] kobject_add_internal+0xb7/0x200
[  604.393217]      [<ffffffff8121eca8>] kobject_add_varg+0x38/0x60
[  604.393220]      [<ffffffff8121ed84>] kobject_add+0x44/0x70
[  604.393223]      [<ffffffff812f8408>] device_add+0x118/0x5d0
[  604.393227]      [<ffffffff8134914d>] usb_new_device+0x6d/0xe0
[  604.393232]      [<ffffffff8134adf8>] hub_thread+0x878/0x1280
[  604.393235]      [<ffffffff810644f6>] kthread+0x96/0xa0
[  604.393240]      [<ffffffff8100c69a>] child_rip+0xa/0x20
[  604.393243]      [<ffffffffffffffff>] 0xffffffffffffffff
===========================================================================

gdb:
==========================================================
(gdb) l *(sysfs_new_dirent+0x10c)
0xffffffff8115ebdc is in sysfs_new_dirent (fs/sysfs/dir.c:315).
310	{
311		char *dup_name = NULL;
312		struct sysfs_dirent *sd;
313	
314		if (type & SYSFS_COPY_NAME) {
315			name = dup_name = kstrdup(name, GFP_KERNEL);
316			if (!name)
317				return NULL;
318		}
319	
=======================================================