From: "Chentao(Boby)" <boby.chen@huawei.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>, konrad.wilk@oracle.com
Cc: liujinlj.liu@huawei.com, xen-devel@lists.xenproject.org,
Yanqiangjun <yanqiangjun@huawei.com>,
zhangmin <rudy.zhangmin@huawei.com>,
wu.wubin@huawei.com
Subject: Re: A memory leak problem in xen-blkback module
Date: Mon, 15 Sep 2014 20:54:50 +0800 [thread overview]
Message-ID: <5416E19A.4080209@huawei.com> (raw)
In-Reply-To: <5416B78F.50208@citrix.com>
On 2014/9/15 17:55, Roger Pau Monné wrote:
> El 12/09/14 a les 8.58, Chentao(Boby) ha escrit:
>> Hi Konrad,
>>
>> I find a memory leak problem in xen-blkback module of linux-3.14.4 release, and the newest 3.17-rc4 also has the same problem. The problem will occur in below condition.
>>
>> In xen_blkbk_map function, first get_free_page from balloon or the list of blkif free pages, then map this page. If get_free_page succeed, but map failed,
>> the grant handle corresponding to this page will be assigned to BLKBACK_INVALID_HANDLE. Because map failed, it will execute xen_blkbk_unmap to retrieve resources.
>> But in xen_blkbk_unmap function, if the grant handle of a page is BLKBACK_INVALID_HANDLE, it will continue to next loop to execute unmap and put_free_pages.
>> Only executes put_free_pages, these pages will be returned to the list of blkif free pages and at last be returned to balloon.
>>
>> Make a summary, in the condition of get_free_page succeed but map failed, the page will be leaked from balloon or the list of blkif free pages. I have a immature thought,
>> in xen_blkbk_unmap funtion, when judge the grant handle of a page is BLKBACK_INVALID_HANDLE, can we execute put_free_pages to retrieve this one page?
>>
>> Just like below:
>> if (pages[i]->handle == BLKBACK_INVALID_HANDLE) {
>> put_free_pages(blkif, pages[i]->page, 1);
>
> This is not correct, and will fail to compile AFAICT. put_free_pages
> expects an array of pointers to page structs and you are passing a
> pointer to a page struct.
>
Thanks for pointing out my code mistake. And I'm very appreciated for your reply.
> I have the following patch, which I think solves the problem. I've
> placed the free_pages call in xen_blkbk_map itself, but it could also
> be done in xen_blkbk_map_unmap.
>
I think the funtion is xen_blkbk_unmap, not xen_blkbk_map_unmap. Am I right?
> ---
> commit 879ebb502e2f72279553bb0a85cc885ec492a0c1
> Author: Roger Pau Monne <roger.pau@citrix.com>
> Date: Mon Sep 15 11:01:40 2014 +0200
>
> xen-blkback: fix leak on grant map error path
>
> Fix leaking a page when a grant mapping has failed.
>
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Reported by: Tao Chen <boby.chen@huawei.com>
> ---
> This patch should be backported to stable branches.
>
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 64c60ed..63fc7f0 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -763,6 +763,7 @@ again:
> BUG_ON(new_map_idx >= segs_to_map);
> if (unlikely(map[new_map_idx].status != 0)) {
> pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
> + put_free_pages(blkif, &pages[seg_idx]->page, 1);
> pages[seg_idx]->handle = BLKBACK_INVALID_HANDLE;
> ret |= 1;
> goto next;
>
>
>
> .
>
next prev parent reply other threads:[~2014-09-15 12:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-12 6:58 A memory leak problem in xen-blkback module Chentao(Boby)
2014-09-15 9:55 ` Roger Pau Monné
2014-09-15 12:54 ` Chentao(Boby) [this message]
2014-09-15 13:15 ` Roger Pau Monné
2014-09-16 1:33 ` Chentao(Boby)
2014-09-30 15:23 ` Roger Pau Monné
2014-10-01 13:46 ` Konrad Rzeszutek Wilk
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=5416E19A.4080209@huawei.com \
--to=boby.chen@huawei.com \
--cc=konrad.wilk@oracle.com \
--cc=liujinlj.liu@huawei.com \
--cc=roger.pau@citrix.com \
--cc=rudy.zhangmin@huawei.com \
--cc=wu.wubin@huawei.com \
--cc=xen-devel@lists.xenproject.org \
--cc=yanqiangjun@huawei.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;
as well as URLs for NNTP newsgroup(s).