From: Jason Wang <jasowang@redhat.com>
To: Dexuan Cui <decui@microsoft.com>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"driverdev-devel@linuxdriverproject.org"
<driverdev-devel@linuxdriverproject.org>,
"olaf@aepfle.de" <olaf@aepfle.de>,
"apw@canonical.com" <apw@canonical.com>,
KY Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Subject: Re: [PATCH] hv: hv_balloon: avoid memory leak on alloc_error of 2MB memory block
Date: Mon, 24 Nov 2014 15:28:06 +0800 [thread overview]
Message-ID: <5472DE06.6000307@redhat.com> (raw)
In-Reply-To: <F792CF86EFE20D4AB8064279AFBA51C613E5FD2B@HKNPRD3002MB017.064d.mgd.msft.net>
On 11/24/2014 02:08 PM, Dexuan Cui wrote:
>> -----Original Message-----
>> > From: Jason Wang [mailto:jasowang@redhat.com]
>> > Sent: Monday, November 24, 2014 13:18 PM
>> > To: Dexuan Cui; gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
>> > driverdev-devel@linuxdriverproject.org; olaf@aepfle.de;
>> > apw@canonical.com; KY Srinivasan
>> > Cc: Haiyang Zhang
>> > Subject: Re: [PATCH] hv: hv_balloon: avoid memory leak on alloc_error of
>> > 2MB memory block
>> >
>> > On 11/24/2014 01:56 PM, Dexuan Cui wrote:
>>> > > If num_ballooned is not 0, we shouldn't neglect the already-allocated
>> > 2MB
>>> > > memory block(s).
>>> > >
>>> > > Cc: K. Y. Srinivasan <kys@microsoft.com>
>>> > > Cc: <stable@vger.kernel.org>
>>> > > Signed-off-by: Dexuan Cui <decui@microsoft.com>
>>> > > ---
>>> > > drivers/hv/hv_balloon.c | 4 +++-
>>> > > 1 file changed, 3 insertions(+), 1 deletion(-)
>>> > >
>>> > > diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
>>> > > index 5e90c5d..cba2d3b 100644
>>> > > --- a/drivers/hv/hv_balloon.c
>>> > > +++ b/drivers/hv/hv_balloon.c
>>> > > @@ -1091,6 +1091,8 @@ static void balloon_up(struct work_struct
>> > *dummy)
>>> > > bool done = false;
>>> > > int i;
>>> > >
>>> > > + /* The host does balloon_up in 2MB. */
>>> > > + WARN_ON(num_pages % PAGES_IN_2M != 0);
>>> > >
>>> > > /*
>>> > > * We will attempt 2M allocations. However, if we fail to
>>> > > @@ -1111,7 +1113,7 @@ static void balloon_up(struct work_struct
>> > *dummy)
>>> > > bl_resp, alloc_unit,
>>> > > &alloc_error);
>>> > >
>>> > > - if ((alloc_error) && (alloc_unit != 1)) {
>>> > > + if (alloc_error && (alloc_unit != 1) && num_ballooned == 0)
>> > {
>>> > > alloc_unit = 1;
>>> > > continue;
>>> > > }
>> >
>> > Before the change, we may retry the 4K allocation when part or all 2M
>> > allocations were failed. This makes sense when memory is fragmented. But
> Yes, but all the partially-allocated 2MB memory blocks are lost(mem leak).
>
>> > after the change, if part of 2M allocation were failed, we won't retry
>> > 4K allocation. Is this expected?
> Hi Jason,
> The patch doesn't break the "try 2MB first; then try 4K" logic:
>
> With the change, we'll retry the 2MB allocation in the next iteration of the
> same while (!done) loop -- we expect this retry will cause
> "alloc_error && (alloc_unit != 1) && num_ballooned == 0" to be true,
> so we'll later try 4K allocation, as we did before.
If I read the code correctly, if part of 2M allocation fails.
alloc_balloon_pages() will have a non zero return value with alloc_error
set. Then it will match the following check:
if ((alloc_error) || (num_ballooned == num_pages))
{
which will set done to true. So there's no second iteration of while
(!done) loop?
Probably you need something like:
if ((alloc_unit != 1) && (num_ballooned == 0)) {
alloc_unit = 1;
continue;
}
if ((alloc_unit == 1) || (num_ballooned = num_pages)) {
...
}
next prev parent reply other threads:[~2014-11-24 7:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-24 5:56 [PATCH] hv: hv_balloon: avoid memory leak on alloc_error of 2MB memory block Dexuan Cui
2014-11-24 5:18 ` Jason Wang
2014-11-24 6:08 ` Dexuan Cui
2014-11-24 7:28 ` Jason Wang [this message]
2014-11-24 7:54 ` Dexuan Cui
2014-11-24 8:47 ` Jason Wang
2014-11-24 8:55 ` Dexuan Cui
2014-11-24 21:55 ` KY Srinivasan
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=5472DE06.6000307@redhat.com \
--to=jasowang@redhat.com \
--cc=apw@canonical.com \
--cc=decui@microsoft.com \
--cc=driverdev-devel@linuxdriverproject.org \
--cc=gregkh@linuxfoundation.org \
--cc=haiyangz@microsoft.com \
--cc=kys@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=olaf@aepfle.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.