From: Johannes Thumshirn <jth@kernel.org>
To: Dennis Zhou <dennis@kernel.org>
Cc: linux-btrfs@vger.kernel.org
Subject: memleaks in btrfs-devel/misc-next
Date: Tue, 7 Jan 2020 12:43:30 +0100 [thread overview]
Message-ID: <b3cfdb33-11d6-b237-c00f-60e1e51f1848@kernel.org> (raw)
Hi Dennis,
When I'm running btrfs/003 and btrfs/004 in my test setup I get the
following kmemleak report:
rapido1:/home/johannes/src/xfstests-dev# cat results/btrfs/004.kmemleak
EXPERIMENTAL kmemleak reported some memory leaks! Due to the way kmemleak
works, the leak might be from an earlier test, or something totally
unrelated.
unreferenced object 0xffff88821eee3c00 (size 1024):
comm "mount", pid 7247, jiffies 4294900263 (age 26.468s)
hex dump (first 32 bytes):
00 b0 ca 2a 82 88 ff ff 00 00 00 00 00 00 00 00 ...*............
00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 ................
backtrace:
[<00000000f993bddc>] btrfs_create_block_group_cache+0x20/0x1a0 [btrfs]
[<00000000e0df8aa6>] btrfs_read_block_groups+0x42f/0x780 [btrfs]
[<00000000792a6ecd>] open_ctree+0x17a8/0x1e93 [btrfs]
[<0000000042fa9fb8>] btrfs_mount_root+0x4e1/0x5a0 [btrfs]
[<00000000586791fa>] legacy_get_tree+0x22/0x40
[<00000000cb72e180>] vfs_get_tree+0x1b/0x90
[<0000000059613ba1>] fc_mount+0x9/0x30
[<00000000a752e56e>] vfs_kern_mount.part.40+0x6a/0x80
[<000000000524dce6>] btrfs_mount+0x138/0x860 [btrfs]
[<00000000586791fa>] legacy_get_tree+0x22/0x40
[<00000000cb72e180>] vfs_get_tree+0x1b/0x90
[<000000005f5112f8>] do_mount+0x674/0x900
[<000000007ead6809>] __x64_sys_mount+0x81/0xd0
[<0000000028386837>] do_syscall_64+0x43/0x140
[<00000000e8583d73>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
unreferenced object 0xffff88821cbdfb40 (size 192):
comm "mount", pid 7247, jiffies 4294900263 (age 26.468s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 cc 00 00 00 00 00 00 00 ................
backtrace:
[<0000000042643477>] btrfs_create_block_group_cache+0x3d/0x1a0 [btrfs]
[<00000000e0df8aa6>] btrfs_read_block_groups+0x42f/0x780 [btrfs]
[<00000000792a6ecd>] open_ctree+0x17a8/0x1e93 [btrfs]
[<0000000042fa9fb8>] btrfs_mount_root+0x4e1/0x5a0 [btrfs]
[<00000000586791fa>] legacy_get_tree+0x22/0x40
[<00000000cb72e180>] vfs_get_tree+0x1b/0x90
[<0000000059613ba1>] fc_mount+0x9/0x30
[<00000000a752e56e>] vfs_kern_mount.part.40+0x6a/0x80
[<000000000524dce6>] btrfs_mount+0x138/0x860 [btrfs]
[<00000000586791fa>] legacy_get_tree+0x22/0x40
[<00000000cb72e180>] vfs_get_tree+0x1b/0x90
[<000000005f5112f8>] do_mount+0x674/0x900
[<000000007ead6809>] __x64_sys_mount+0x81/0xd0
[<0000000028386837>] do_syscall_64+0x43/0x140
[<00000000e8583d73>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
I've bisected it down to:
63c3d72cf65e ("btrfs: add the beginning of async discard, discard
workqueue")
The backtrace points to this:
(gdb) l *(btrfs_create_block_group_cache+0x20)
0xa8060 is in btrfs_create_block_group_cache (fs/btrfs/block-group.c:1641).
1636 struct btrfs_fs_info *fs_info, u64 start, u64 size)
1637 {
1638 struct btrfs_block_group *cache;
1639
1640 cache = kzalloc(sizeof(*cache), GFP_NOFS);
1641 if (!cache)
1642 return NULL;
1643
1644 cache->free_space_ctl =
kzalloc(sizeof(*cache->free_space_ctl),
1645 GFP_NOFS);
(gdb) l *(btrfs_create_block_group_cache+0x3d)
0xa807d is in btrfs_create_block_group_cache (fs/btrfs/block-group.c:1646).
1641 if (!cache)
1642 return NULL;
1643
1644 cache->free_space_ctl =
kzalloc(sizeof(*cache->free_space_ctl),
1645 GFP_NOFS);
1646 if (!cache->free_space_ctl) {
1647 kfree(cache);
1648 return NULL;
1649 }
1650
so we're leaking both cache and cache->free_space_ctl.
I'm looking into it right now but maybe you're faster seeing what's
missing here.
Byte,
Johannes
next reply other threads:[~2020-01-07 11:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-07 11:43 Johannes Thumshirn [this message]
2020-01-07 18:04 ` memleaks in btrfs-devel/misc-next Dennis Zhou
2020-01-08 0:31 ` Dennis Zhou
2020-01-08 7:28 ` Johannes Thumshirn
2020-01-08 13:02 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b3cfdb33-11d6-b237-c00f-60e1e51f1848@kernel.org \
--to=jth@kernel.org \
--cc=dennis@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox