[2.6.31-rc6, BTRFS] potential memory leaks...

[2.6.31-rc6, BTRFS] potential memory leaks...

[Daniel J Blueman]

There is good chance that the BTRFS kmemleak reports using 2.6.31-rc6
[1] are false-positives, due to the overwriting of the static pointers
[2]. Does this ring true with anyone else?

--- [1]

unreferenced object 0xffff88001eda7000 (size 168):
  comm "rm", pid 14794, jiffies 4301710929
  backtrace:
    [<ffffffff810de2f1>] create_object+0x141/0x2d0
    [<ffffffff810de5c5>] kmemleak_alloc+0x55/0x60
    [<ffffffff810d9f73>] kmem_cache_alloc+0x153/0x1a0
    [<ffffffff811df959>] alloc_extent_state+0x19/0x70
    [<ffffffff811e1eb3>] clear_extent_bit+0x233/0x2e0
    [<ffffffff811e20ee>] try_release_extent_state+0x7e/0xa0
    [<ffffffff811bf7f3>] btree_releasepage+0x63/0xa0
    [<ffffffff810ad0be>] try_to_release_page+0x2e/0x60
    [<ffffffff810b872c>] invalidate_mapping_pages+0x1ac/0x1c0
    [<ffffffff811b746a>] __btrfs_free_extent+0x56a/0x8e0
    [<ffffffff811b7c9d>] run_one_delayed_ref+0x4bd/0x4f0
    [<ffffffff811b9a8f>] run_clustered_refs+0xcf/0x360
    [<ffffffff811b9de6>] btrfs_run_delayed_refs+0xc6/0x1f0
    [<ffffffff811c4129>] __btrfs_end_transaction+0x59/0x130
    [<ffffffff811c421b>] btrfs_end_transaction+0xb/0x10
    [<ffffffff811cc6d2>] btrfs_delete_inode+0x112/0x130

unreferenced object 0xffff88006c5912a0 (size 168):
  comm "make", pid 3983, jiffies 4296054079
  backtrace:
    [<ffffffff810de2f1>] create_object+0x141/0x2d0
    [<ffffffff810de5c5>] kmemleak_alloc+0x55/0x60
    [<ffffffff810d9f73>] kmem_cache_alloc+0x153/0x1a0
    [<ffffffff811df959>] alloc_extent_state+0x19/0x70
    [<ffffffff811e0cae>] set_extent_bit+0x1ee/0x390
    [<ffffffff811e1a73>] lock_extent+0x73/0xa0
    [<ffffffff811e27a7>] __extent_read_full_page+0x97/0x610
    [<ffffffff811e3119>] read_extent_buffer_pages+0x3f9/0x540
    [<ffffffff811bf75f>] readahead_tree_block+0x4f/0x60
    [<ffffffff811a7e03>] read_block_for_search+0x2f3/0x3b0
    [<ffffffff811b003b>] btrfs_next_leaf+0x28b/0x3f0
    [<ffffffff811c5cea>] btrfs_real_readdir+0x1ca/0x4e0
    [<ffffffff810f0580>] vfs_readdir+0xb0/0xd0
    [<ffffffff810f06f7>] sys_getdents+0x87/0xe0
    [<ffffffff8100bdeb>] system_call_fastpath+0x16/0x1b

unreferenced object 0xffff88003bf5d800 (size 256):
  comm "btrfs-transacti", pid 2060, jiffies 4301667515
  backtrace:
    [<ffffffff810de2f1>] create_object+0x141/0x2d0
    [<ffffffff810de5c5>] kmemleak_alloc+0x55/0x60
    [<ffffffff810d9f73>] kmem_cache_alloc+0x153/0x1a0
    [<ffffffff811dfa29>] alloc_extent_buffer+0x79/0x3e0
    [<ffffffff811bf688>] btrfs_find_create_tree_block+0x28/0x30
    [<ffffffff811b46a1>] btrfs_init_new_buffer+0x31/0x140
    [<ffffffff811b4854>] btrfs_alloc_free_block+0xa4/0x230
    [<ffffffff811ac2d7>] __btrfs_cow_block+0x137/0x670
    [<ffffffff811acf0f>] btrfs_cow_block+0xef/0x1f0
    [<ffffffff811af6ba>] btrfs_search_slot+0x19a/0x890
    [<ffffffff811bd1ee>] btrfs_del_csums+0xee/0x2e0
    [<ffffffff811b75b9>] __btrfs_free_extent+0x6b9/0x8e0
    [<ffffffff811b7be2>] run_one_delayed_ref+0x402/0x4f0
    [<ffffffff811b9a8f>] run_clustered_refs+0xcf/0x360
    [<ffffffff811b9de6>] btrfs_run_delayed_refs+0xc6/0x1f0
    [<ffffffff811c4a8a>] btrfs_commit_transaction+0x7a/0x750

unreferenced object 0xffff8800668e8600 (size 256):
  comm "btrfs-endio-wri", pid 2053, jiffies 4301877227
  backtrace:
    [<ffffffff810de2f1>] create_object+0x141/0x2d0
    [<ffffffff810de5c5>] kmemleak_alloc+0x55/0x60
    [<ffffffff810d9f73>] kmem_cache_alloc+0x153/0x1a0
    [<ffffffff811dfa29>] alloc_extent_buffer+0x79/0x3e0
    [<ffffffff811bf688>] btrfs_find_create_tree_block+0x28/0x30
    [<ffffffff811b46a1>] btrfs_init_new_buffer+0x31/0x140
    [<ffffffff811b4854>] btrfs_alloc_free_block+0xa4/0x230
    [<ffffffff811ac2d7>] __btrfs_cow_block+0x137/0x670
    [<ffffffff811acf0f>] btrfs_cow_block+0xef/0x1f0
    [<ffffffff811af6ba>] btrfs_search_slot+0x19a/0x890
    [<ffffffff811b0819>] btrfs_insert_empty_items+0x69/0xd0
    [<ffffffff811b7998>] run_one_delayed_ref+0x1b8/0x4f0
    [<ffffffff811b9a8f>] run_clustered_refs+0xcf/0x360
    [<ffffffff811b9de6>] btrfs_run_delayed_refs+0xc6/0x1f0
    [<ffffffff811c4129>] __btrfs_end_transaction+0x59/0x130
    [<ffffffff811c421b>] btrfs_end_transaction+0xb/0x10

--- [2] fs/btrfs/extent_io.c:46

static struct kmem_cache *extent_state_cache;
static struct kmem_cache *extent_buffer_cache
-- 
Daniel J Blueman

Re: [2.6.31-rc6, BTRFS] potential memory leaks...

[Chris Mason]

On Fri, Aug 14, 2009 at 04:03:04PM +0100, Daniel J Blueman wrote:
> There is good chance that the BTRFS kmemleak reports using 2.6.31-rc6
> [1] are false-positives, due to the overwriting of the static pointers
> [2]. Does this ring true with anyone else?

If these were real leaks you'd see errors during rmmod.  They should be
false positives.

-chris

Re: [2.6.31-rc6, BTRFS] potential memory leaks...

[Catalin Marinas]

Daniel J Blueman <daniel.blueman@gmail.com> wrote:
> There is good chance that the BTRFS kmemleak reports using 2.6.31-rc6
> [1] are false-positives, due to the overwriting of the static pointers
> [2]. Does this ring true with anyone else?

If you do a few echo scan > /sys/kernel/debug/kmemleak, do they
disappear?

The static pointers are scanned by kmemleak, unless they are in the
.data.init section (which is removed anyway).

-- 
Catalin

Re: [2.6.31-rc6, BTRFS] potential memory leaks...

[Daniel J Blueman]

On Fri, Aug 14, 2009 at 5:35 PM, Catalin Marinas<catalin.marinas@arm.com> wrote:
> Daniel J Blueman <daniel.blueman@gmail.com> wrote:
>> There is good chance that the BTRFS kmemleak reports using 2.6.31-rc6
>> [1] are false-positives, due to the overwriting of the static pointers
>> [2]. Does this ring true with anyone else?
>
> If you do a few echo scan > /sys/kernel/debug/kmemleak, do they
> disappear?
>
> The static pointers are scanned by kmemleak, unless they are in the
> .data.init section (which is removed anyway).

The above reports I picked _are_ transient indeed.

Directed more to LKML, every mount (at least on ext4 and BTRFS), we do
see persistent reports [1], even after scanning, unmount and more
scanning.

Daniel

--- [1]

unreferenced object 0xffff88006133d260 (size 32):
  comm "mount", pid 27209, jiffies 4300626089
  backtrace:
    [<ffffffff810de2f1>] create_object+0x141/0x2d0
    [<ffffffff810de5c5>] kmemleak_alloc+0x55/0x60
    [<ffffffff810dadfb>] __kmalloc_track_caller+0x17b/0x260
    [<ffffffff810c1429>] kstrdup+0x39/0x70
    [<ffffffffa01d2b9a>] btrfs_parse_options+0x5a/0x3a0 [btrfs]
    [<ffffffffa01edf45>] open_ctree+0x9c5/0x13f0 [btrfs]
    [<ffffffffa01d24ec>] btrfs_get_sb+0x3fc/0x500 [btrfs]
    [<ffffffff810e2478>] vfs_kern_mount+0x58/0xd0
    [<ffffffff810e255e>] do_kern_mount+0x4e/0x110
    [<ffffffff810fc55a>] do_mount+0x2ca/0x8d0
    [<ffffffff810fcc1b>] sys_mount+0xbb/0xf0
    [<ffffffff8100bdeb>] system_call_fastpath+0x16/0x1b

unreferenced object 0xffff88007a5d9c80 (size 128):
  comm "mount", pid 2030, jiffies 4294963872
  backtrace:
    [<ffffffff810de2f1>] create_object+0x141/0x2d0
    [<ffffffff810de5c5>] kmemleak_alloc+0x55/0x60
    [<ffffffff810da14b>] __kmalloc+0x18b/0x270
    [<ffffffff81162c8d>] ext4_mb_init+0x1cd/0x670
    [<ffffffff8114e363>] ext4_fill_super+0x1883/0x2810
    [<ffffffff810e388d>] get_sb_bdev+0x17d/0x1b0
    [<ffffffff8114a8c3>] ext4_get_sb+0x13/0x20
    [<ffffffff810e2478>] vfs_kern_mount+0x58/0xd0
    [<ffffffff810e255e>] do_kern_mount+0x4e/0x110
    [<ffffffff810fc55a>] do_mount+0x2ca/0x8d0
    [<ffffffff810fcc1b>] sys_mount+0xbb/0xf0
    [<ffffffff8100bdeb>] system_call_fastpath+0x16/0x1b

unreferenced object 0xffff88006071a000 (size 8192):
  comm "mount", pid 27460, jiffies 4303151389
  backtrace:
    [<ffffffff810de2f1>] create_object+0x141/0x2d0
    [<ffffffff810de5c5>] kmemleak_alloc+0x55/0x60
    [<ffffffff810d9f73>] kmem_cache_alloc+0x153/0x1a0
    [<ffffffff81171ec7>] journal_init_common+0x1e7/0x2a0
    [<ffffffff81172995>] jbd2_journal_init_inode+0x15/0x1b0
    [<ffffffff8114e869>] ext4_fill_super+0x1d89/0x2810
    [<ffffffff810e388d>] get_sb_bdev+0x17d/0x1b0
    [<ffffffff8114a8c3>] ext4_get_sb+0x13/0x20
    [<ffffffff810e2478>] vfs_kern_mount+0x58/0xd0
    [<ffffffff810e255e>] do_kern_mount+0x4e/0x110
    [<ffffffff810fc55a>] do_mount+0x2ca/0x8d0
    [<ffffffff810fcc1b>] sys_mount+0xbb/0xf0
    [<ffffffff8100bdeb>] system_call_fastpath+0x16/0x1b
-- 
Daniel J Blueman

Re: [2.6.31-rc6, BTRFS] potential memory leaks...

[Catalin Marinas]

On Sun, 2009-08-16 at 13:55 +0100, Daniel J Blueman wrote:
> On Fri, Aug 14, 2009 at 5:35 PM, Catalin Marinas<catalin.marinas@arm.com> wrote:
> > Daniel J Blueman <daniel.blueman@gmail.com> wrote:
> >> There is good chance that the BTRFS kmemleak reports using 2.6.31-rc6
> >> [1] are false-positives, due to the overwriting of the static pointers
> >> [2]. Does this ring true with anyone else?
> >
> > If you do a few echo scan > /sys/kernel/debug/kmemleak, do they
> > disappear?
> >
> > The static pointers are scanned by kmemleak, unless they are in the
> > .data.init section (which is removed anyway).
> 
> The above reports I picked _are_ transient indeed.

In earlier versions of kmemleak, a block required two successive
classifications as leak before being reported. Maybe I should go back to
this approach.

> Directed more to LKML, every mount (at least on ext4 and BTRFS), we do
> see persistent reports [1], even after scanning, unmount and more
> scanning.

The ext4 leak is real and a patch was proposed here:
http://lkml.org/lkml/2009/7/15/62

It seems that this patch hasn't been merged into mainline yet (in the
meantime I merged it in my "kmemleak-fixes" branch on
git://linux-arm.org/linux-2.6.git)

-- 
Catalin