Hi Johannes and Catalin,
Actually bisecting is the best way, but I failed to run fsstress with
early 3.15-rcX due to BUG_ONs in mm; recently it seems that most of
there-in issues have been resolved.
So I pulled the linus tree having:
commit 38583f095c5a8138ae2a1c9173d0fd8a9f10e8aa
Merge: 8169d30 3ca9e5d
Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Date: Tue May 6 13:07:41 2014 -0700
Merge branch 'akpm' (incoming from Andrew)
Merge misc fixes from Andrew Morton:
"13 fixes"
And then when I tested again with Catalin's patch, it still throws the
following warning.
Is it false alarm?
unreferenced object 0xffff880004226da0 (size 576):
comm "fsstress", pid 14590, jiffies 4295191259 (age 706.308s)
hex dump (first 32 bytes):
01 00 00 00 81 ff ff ff 00 00 00 00 00 00 00 00 ................
50 89 34 81 ff ff ff ff b8 6d 22 04 00 88 ff ff P.4......m".....
backtrace:
[<ffffffff816c02e8>] kmemleak_update_trace+0x58/0x80
[<ffffffff81349517>] radix_tree_node_alloc+0x77/0xa0
[<ffffffff81349718>] __radix_tree_create+0x1d8/0x230
[<ffffffff8113286c>] __add_to_page_cache_locked+0x9c/0x1b0
[<ffffffff811329a8>] add_to_page_cache_lru+0x28/0x80
[<ffffffff81132f58>] grab_cache_page_write_begin+0x98/0xf0
[<ffffffffa02e4bf4>] f2fs_write_begin+0xb4/0x3c0 [f2fs]
[<ffffffff81131b77>] generic_perform_write+0xc7/0x1c0
[<ffffffff81133b7d>] __generic_file_aio_write+0x1cd/0x3f0
[<ffffffff81133dfe>] generic_file_aio_write+0x5e/0xe0
[<ffffffff81195c5a>] do_sync_write+0x5a/0x90
[<ffffffff811968d2>] vfs_write+0xc2/0x1d0
[<ffffffff81196daf>] SyS_write+0x4f/0xb0
[<ffffffff816dead2>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
2014-05-01 (목), 14:41 -0400, Johannes Weiner:
> On Thu, May 01, 2014 at 06:06:10PM +0100, Catalin Marinas wrote:
> > On Fri, Apr 25, 2014 at 10:45:40AM +0900, Jaegeuk Kim wrote:
> > > 2. Bug
> > > This is one of the results, but all the results indicate
> > > __radix_tree_preload.
> > >
> > > unreferenced object 0xffff88002ae2a238 (size 576):
> > > comm "fsstress", pid 25019, jiffies 4295651360 (age 2276.104s)
> > > hex dump (first 32 bytes):
> > > 01 00 00 00 81 ff ff ff 00 00 00 00 00 00 00 00 ................
> > > 40 7d 37 81 ff ff ff ff 50 a2 e2 2a 00 88 ff ff @}7.....P..*....
> > > backtrace:
> > > [<ffffffff8170e546>] kmemleak_alloc+0x26/0x50
> > > [<ffffffff8119feac>] kmem_cache_alloc+0xdc/0x190
> > > [<ffffffff81378709>] __radix_tree_preload+0x49/0xc0
> > > [<ffffffff813787a1>] radix_tree_maybe_preload+0x21/0x30
> > > [<ffffffff8114bbbc>] add_to_page_cache_lru+0x3c/0xc0
> > > [<ffffffff8114c778>] grab_cache_page_write_begin+0x98/0xf0
> > > [<ffffffffa02d3151>] f2fs_write_begin+0xa1/0x370 [f2fs]
> > > [<ffffffff8114af47>] generic_perform_write+0xc7/0x1e0
> > > [<ffffffff8114d230>] __generic_file_aio_write+0x1d0/0x400
> > > [<ffffffff8114d4c0>] generic_file_aio_write+0x60/0xe0
> > > [<ffffffff811b281a>] do_sync_write+0x5a/0x90
> > > [<ffffffff811b3575>] vfs_write+0xc5/0x1f0
> > > [<ffffffff811b3a92>] SyS_write+0x52/0xb0
> > > [<ffffffff81730912>] system_call_fastpath+0x16/0x1b
> > > [<ffffffffffffffff>] 0xffffffffffffffff
> >
> > Do all the backtraces look like the above (coming from
> > add_to_page_cache_lru)?
Yap.
> >
> > There were some changes in lib/radix-tree.c since 3.14, maybe you could
> > try reverting them and see if the leaks still appear (cc'ing Johannes).
> > It could also be a false positive.
> >
> > An issue with debugging such cases is that the preloading is common for
> > multiple radix trees, so the actual radix_tree_node_alloc() could be on
> > a different path. You could give the patch below a try to see what
> > backtrace you get (it updates backtrace in radix_tree_node_alloc()).
>
> That patch makes a lot of sense to me. I applied it locally but I am
> unable to reproduce this with page cache heavy workloads. Jaegeuk?
--
Jaegeuk Kim
Samsung
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href