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 pk......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

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

On Mon, Jul 02, 2012 at 03:14:12PM -0400, Mike Snitzer wrote:
> 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.
--
Dave Chinner
david@fromorbit.com

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

On Mon, Jul 02 2012 at 8:26pm -0400,
Dave Chinner <david@fromorbit.com> wrote:

> On Mon, Jul 02, 2012 at 03:14:12PM -0400, Mike Snitzer wrote:
> > 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.

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

On Mon, Jul 02, 2012 at 09:26:28PM -0400, Mike Snitzer wrote:
> On Mon, Jul 02 2012 at 8:26pm -0400,
> Dave Chinner <david@fromorbit.com> wrote:
>
> > On Mon, Jul 02, 2012 at 03:14:12PM -0400, Mike Snitzer wrote:
> > > 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.
--
Dave Chinner
david@fromorbit.com


xfs: really first cursor leak in xfs_alloc_ag_vextent_near

From: Dave Chinner <dchinner@redhat.com>

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 <dchinner@redhat.com>
---
fs/xfs/xfs_alloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/xfs/xfs_alloc.c b/fs/xfs/xfs_alloc.c
index 9d1aeb7..f654f51 100644
--- a/fs/xfs/xfs_alloc.c
+++ b/fs/xfs/xfs_alloc.c
@@ -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;

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

On Mon, Jul 02 2012 at 11:21pm -0400,
Dave Chinner <david@fromorbit.com> wrote:

> On Mon, Jul 02, 2012 at 09:26:28PM -0400, Mike Snitzer wrote:
> > On Mon, Jul 02 2012 at 8:26pm -0400,
> > Dave Chinner <david@fromorbit.com> wrote:
> >
> > > On Mon, Jul 02, 2012 at 03:14:12PM -0400, Mike Snitzer wrote:
> > > > 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.

Looks good. Thanks.

Tested-by: Mike Snitzer <snitzer@redhat.com>

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel