From: Nikolay Borisov <nborisov@suse.com>
To: fdmanana@gmail.com, robbieko <robbieko@synology.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] btrfs: fix memory leak for page count
Date: Fri, 17 Jul 2020 15:27:56 +0300 [thread overview]
Message-ID: <ee3f2b3e-06a2-e5d7-7c44-eb9bd1eca5b4@suse.com> (raw)
In-Reply-To: <CAL3q7H4+yzwLm6yhSfmSLbh6d00geGQsM-h6TiZzgAQHWT+yiQ@mail.gmail.com>
On 17.07.20 г. 15:00 ч., Filipe Manana wrote:
> On Fri, Jul 17, 2020 at 11:23 AM robbieko <robbieko@synology.com> wrote:
>>
>> From: Robbie Ko <robbieko@synology.com>
>>
>> When lock_delalloc_page, we first lock the page and then
>> check that the page dirty, if the page is not dirty, we
>> will return -EAGAIN but all pages must be freed, otherwise
>> page leak.
>
> "When lock_delalloc_page" -> When locking pages for delalloc
>
> We check if it's dirty and if the mapping still matches.
>
> Btw, you can make line length closer to 75 characters, it makes things
> a bit more readable.
>
> The subject is also a bit confusing:
>
> "btrfs: fix memory leak for page count"
>
> something along the lines "btrfs: fix page leaks after failure to lock
> page for delalloc" would be more clear to me at least,
> it gives a clue about where the problem is.
>
>>
>> Signed-off-by: Robbie Ko <robbieko@synology.com>
>
> The code looks correct, thanks.
>
> Reviewed-by: Filipe Manana <fdmanana@suse.com>
>
>> ---
>> fs/btrfs/extent_io.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
>> index 68c96057ad2d..34d55b1e2a88 100644
>> --- a/fs/btrfs/extent_io.c
>> +++ b/fs/btrfs/extent_io.c
>> @@ -1951,7 +1951,7 @@ static int __process_pages_contig(struct address_space *mapping,
>> struct page *pages[16];
>> unsigned ret;
>> int err = 0;
>> - int i;
>> + int i, j;
>>
>> if (page_ops & PAGE_LOCK) {
>> ASSERT(page_ops == PAGE_LOCK);
>> @@ -1999,7 +1999,8 @@ static int __process_pages_contig(struct address_space *mapping,
>> if (!PageDirty(pages[i]) ||
>> pages[i]->mapping != mapping) {
>> unlock_page(pages[i]);
>> - put_page(pages[i]);
>> + for (j = i; j < ret; j++)
>> + put_page(pages[j]);
nit: You don't need to introduce another variable, you can simply reuse
i from its current value:
for(; i < ret; i++)
put_pages(pages[j]
If 'j' is to be used I'da rather have it defined in the 'if' branch so
it's lifespan is clearly visible.
>> err = -EAGAIN;
>> goto out;
>> }
>> --
>> 2.17.1
>>
>
>
next prev parent reply other threads:[~2020-07-17 12:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-17 10:22 [PATCH] btrfs: fix memory leak for page count robbieko
2020-07-17 12:00 ` Filipe Manana
2020-07-17 12:27 ` Nikolay Borisov [this message]
2020-07-20 1:27 ` Robbie Ko
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=ee3f2b3e-06a2-e5d7-7c44-eb9bd1eca5b4@suse.com \
--to=nborisov@suse.com \
--cc=fdmanana@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=robbieko@synology.com \
/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