[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151123135342.GJ23418@quack.suse.cz>
Date: Mon, 23 Nov 2015 14:53:42 +0100
From: Jan Kara <jack@...e.cz>
To: Namjae Jeon <namjae.jeon@...sung.com>
Cc: 'Jan Kara' <jack@...e.cz>, 'Theodore Ts'o' <tytso@....edu>,
linux-ext4@...r.kernel.org
Subject: Re: memory leak: data=journal and {collapse,insert,zero}_range
On Fri 20-11-15 13:34:36, Namjae Jeon wrote:
> Actually, I can quickly create memleak with simple testcase like:
> while(1000)
> {
> Random seek(max 500M) -> write 1M -> fsync ->truncate(random size)
> }
>
> As there is significant memleak in this situation also, I started focusing
> on this simple testcase only. When use this testcase, I never saw EBUSY path
> in jbd2_journal_invalidatepage() -> journal_unmap_buffer().
>
> On the other hand(), for memleak pages jbd2_journal_invalidatepage() ->
> journal_unmap_buffer() was almost bailing out every time from
> if (!buffer_dirty(bh)) {
> /* bdflush has written it. We can drop it now */
> goto zap_buffer;
> }
>
> As per debugging, NULL mapping page or buffer is created in below scenario:
> Write(or Kjournald) -> jbd2_journal_commit_transaction
> -> BH_JBDDirty buffer is added to forget list.
> -> Buffer is added to new checkpoint,
> additional reference count is taken on b_jcount which
> keeps buffer busy until remove checkpoint.
> -> Buffer is unfiled, removed from forget list, BH_JBDDirty
> is cleared and BH_Dirty is set, it is exposed to VM.
Ah, I see! Thanks for the easy reproduction testcase and for the debugging.
Attached patch fixes the issue (at least the simple truncate case) for me.
Can you check whether it fixes the issue for you as well? Thanks!
Honza
--
Jan Kara <jack@...e.com>
SUSE Labs, CR
View attachment "0001-jbd2-Fix-unreclaimed-pages-after-truncate-in-data-jo.patch" of type "text/x-patch" (2207 bytes)
Powered by blists - more mailing lists