From: Jaegeuk Kim <jaegeuk.kim@samsung.com>
To: Johannes Weiner <hannes@cmpxchg.org>,
Catalin Marinas <catalin.marinas@arm.com>
Cc: "Linux Kernel, Mailing List" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [BUG] kmemleak on __radix_tree_preload
Date: Wed, 07 May 2014 11:58:08 +0900 [thread overview]
Message-ID: <1399431488.13268.29.camel@kjgkr> (raw)
In-Reply-To: <20140501184112.GH23420@cmpxchg.org>
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@linux-foundation.org>
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
next prev parent reply other threads:[~2014-05-07 3:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-25 1:45 [BUG] kmemleak on __radix_tree_preload Jaegeuk Kim
2014-05-01 17:06 ` Catalin Marinas
2014-05-01 18:41 ` Johannes Weiner
2014-05-07 2:58 ` Jaegeuk Kim [this message]
2014-05-07 11:39 ` Catalin Marinas
2014-05-08 9:16 ` Jaegeuk Kim
2014-05-08 9:26 ` Catalin Marinas
2014-05-08 9:37 ` Jaegeuk Kim
2014-05-08 10:24 ` Catalin Marinas
2014-05-08 15:00 ` Paul E. McKenney
2014-05-08 15:29 ` Catalin Marinas
2014-05-08 15:53 ` Paul E. McKenney
2014-05-08 16:52 ` Catalin Marinas
2014-05-09 0:06 ` Jaegeuk Kim
2014-05-08 17:52 ` Johannes Weiner
2014-05-08 21:40 ` Catalin Marinas
2014-05-09 0:01 ` Jaegeuk Kim
2014-05-09 9:45 ` Catalin Marinas
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=1399431488.13268.29.camel@kjgkr \
--to=jaegeuk.kim@samsung.com \
--cc=catalin.marinas@arm.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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;
as well as URLs for NNTP newsgroup(s).