Skip to contentSkip to conversation

xfs_btree_cur leak with 3.5-rc4

DISCUSSION Mike Snitzer 2 participants 5 messages Jul 2, 2012 – Jul 3, 2012

Subsystems (2)
Device mapper XFS filesystem
lore
Share & tools
lore

Mike Snitzer

author
#0 lore raw

I get kmemleak reports against XFS when I run the thinp-test-suite against 3.5-rc4. I didn't see any XFS leaks with 3.4.

kmemleak reports:

unreferenced object 0xffff8802767798a0 (size 208):
comm "kworker/4:1", pid 25239, jiffies 4799921469 (age 5830.005s) hex dump (first 32 bytes):

    70 5c 6b ab 02 88 ff ff 00 58 0d 2c 03 88 ff ff  p\k......X.,....
    c0 8e 7d a0 ff ff ff ff 04 00 00 00 00 00 00 00  ..}.............
  backtrace:
    [<ffffffff814b6e3e>] kmemleak_alloc+0x5e/0xc0
    [<ffffffff8114c4b3>] kmem_cache_alloc+0x103/0x1d0
    [<ffffffffa078d987>] kmem_zone_alloc+0x77/0xf0 [xfs]
    [<ffffffffa078da1e>] kmem_zone_zalloc+0x1e/0x50 [xfs]
    [<ffffffffa0791c4c>] xfs_allocbt_init_cursor+0x4c/0xd0 [xfs]
    [<ffffffffa07902a8>] xfs_alloc_ag_vextent_near+0x68/0xb70 [xfs]
    [<ffffffffa0790e85>] xfs_alloc_ag_vextent+0xd5/0x100 [xfs]
    [<ffffffffa0791744>] __xfs_alloc_vextent+0x2a4/0x5f0 [xfs]
    [<ffffffffa0791ada>] xfs_alloc_vextent_worker+0x4a/0x80 [xfs]
    [<ffffffff8105a3f2>] process_one_work+0x132/0x450
    [<ffffffff8105c1fb>] worker_thread+0x17b/0x3c0
    [<ffffffff8106137e>] kthread+0x9e/0xb0
    [<ffffffff814d7ca4>] kernel_thread_helper+0x4/0x10
    [<ffffffffffffffff>] 0xffffffffffffffff

unloading the xfs module reports:

slab error in kmem_cache_destroy(): cache `xfs_btree_cur': Can't free all objects
Pid: 26305, comm: modprobe Tainted: G W O 3.5.0-rc4.cache+ #2

Call Trace:
 [<ffffffff8114ca3f>] kmem_cache_destroy+0xaf/0xe0
 [<ffffffffa0788074>] xfs_destroy_zones+0xc4/0x110 [xfs]
 [<ffffffffa07d32b3>] exit_xfs_fs+0x33/0x35 [xfs]
 [<ffffffff8109f82f>] sys_delete_module+0x1cf/0x2c0
 [<ffffffff810bb39c>] ? __audit_syscall_entry+0xcc/0x210
 [<ffffffff814d69a9>] system_call_fastpath+0x16/0x1b

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

#1 lore raw
Quoted 2 lines · Mike Snitzer

I get kmemleak reports against XFS when I run the thinp-test-suite against 3.5-rc4. I didn't see any XFS leaks with 3.4.

Already fixed in 3.5-rc5:

76d0953 xfs: fix allocbt cursor leak in xfs_alloc_ag_vextent_near

Thanks for reporting it, though, Mike.

Cheers,

Dave.

Signature · 7 lines
Dave Chinner
[email protected]

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
author
#2 lore raw
Quoted 7 lines · Dave Chinner
Quoted 2 lines · Mike Snitzer

I get kmemleak reports against XFS when I run the thinp-test-suite against 3.5-rc4. I didn't see any XFS leaks with 3.4.

Already fixed in 3.5-rc5:

76d0953 xfs: fix allocbt cursor leak in xfs_alloc_ag_vextent_near

Odd, I already have that fix (as it was included in 3.5-rc4).

I'll double check though I see the leak though.

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

#3 lore raw
Quoted 4 lines · Mike Snitzer
Quoted 1 line · Dave Chinner

On Mon, Jul 02, 2012 at 03:14:12PM -0400, Mike Snitzer wrote:

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

I get kmemleak reports against XFS when I run the thinp-test-suite against 3.5-rc4. I didn't see any XFS leaks with 3.4.

Already fixed in 3.5-rc5:

76d0953 xfs: fix allocbt cursor leak in xfs_alloc_ag_vextent_near

Odd, I already have that fix (as it was included in 3.5-rc4).

I misread the git describe as saying it was included after -rc4. My mistake. That indicates that the above fix wasn't quite correct...

Try the patch below.

Cheers,

Dave.

Signature · 16 lines
Dave Chinner
[email protected]


xfs: really first cursor leak in xfs_alloc_ag_vextent_near

From: Dave Chinner <[email protected]>

The current cursor is reallocated when retrying the allocation, so
the exist cursor needs to be destroyed in both the restart and the
failure case.

Signed-off-by: Dave Chinner <[email protected]>
---
 fs/xfs/xfs_alloc.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
fs/xfs/xfs_alloc.c +2 -2
index 9d1aeb7..f654f51 100644
@@ -1074,13 +1074,13 @@ restart:
 	 * If we couldn't get anything, give up.
 	 */
 	if (bno_cur_lt == NULL && bno_cur_gt == NULL) {
+		xfs_btree_del_cursor(cnt_cur, XFS_BTREE_NOERROR);
+
 		if (!forced++) {
 			trace_xfs_alloc_near_busy(args);
 			xfs_log_force(args->mp, XFS_LOG_SYNC);
 			goto restart;
 		}
-
-		xfs_btree_del_cursor(cnt_cur, XFS_BTREE_NOERROR);
 		trace_xfs_alloc_size_neither(args);
 		args->agbno = NULLAGBLOCK;
 		return 0;

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

author Tested-by
#4 lore raw
Quoted 10 lines · Dave Chinner
Quoted 9 lines · Mike Snitzer
Quoted 6 lines · Dave Chinner
Quoted 2 lines · Mike Snitzer

I get kmemleak reports against XFS when I run the thinp-test-suite against 3.5-rc4. I didn't see any XFS leaks with 3.4.

Already fixed in 3.5-rc5:

Quoted 8 lines
Quoted 3 lines
Quoted 1 line

76d0953 xfs: fix allocbt cursor leak in xfs_alloc_ag_vextent_near

Odd, I already have that fix (as it was included in 3.5-rc4).

I misread the git describe as saying it was included after -rc4. My mistake. That indicates that the above fix wasn't quite correct...

Try the patch below.

Looks good. Thanks.

Tested-by Mike Snitzer <[email protected]>

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs