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

[Catalin Marinas]

(I cc'ed linux-ext4@xxxxxxxxxxxxxxx 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

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