From: Glauber Costa <glommer@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
aliguori@codemonkey.ws, npiggin@suse.de,
Jeremy Fitzhardinge <jeremy@goop.org>,
Krzysztof Helt <krzysztof.h1@poczta.fm>
Subject: Re: [PATCH] regression: vmalloc easily fail.
Date: Tue, 28 Oct 2008 19:09:47 -0200 [thread overview]
Message-ID: <20081028210947.GA4269@poweredge.glommer> (raw)
In-Reply-To: <49077E1A.5080105@redhat.com>
On Tue, Oct 28, 2008 at 11:03:22PM +0200, Avi Kivity wrote:
> Glauber Costa wrote:
>> Commit db64fe02258f1507e13fe5212a989922323685ce broke
>> KVM (the symptom) for me. The cause is that vmalloc
>> allocations fail, despite of the fact that /proc/meminfo
>> shows plenty of vmalloc space available.
>>
>> After some investigation, it seems to me that the current
>> way to compute the next addr in the rb-tree transversal
>> leaves a spare page between each allocation. After a few
>> allocations, regardless of their size, we run out of vmalloc
>> space.
>>
>> while (addr + size >= first->va_start && addr + size <= vend) {
>> - addr = ALIGN(first->va_end + PAGE_SIZE, align);
>> + addr = ALIGN(first->va_end, align);
>> n = rb_next(&first->rb_node);
>> if (n)
>>
>
> I'm guessing that the missing comment explains that this is intentional,
> to trap buffer overflows?
>
> (okay that was a cheap shot. I don't comment nearly enough either)
>
> Even if you leave a page between allocations, I don't see how you can
> fail a one page allocation, unless you've allocated at least N/2 pages
> (where N is the size of the vmalloc space in pages).
I'm hoping Nick will comment on it. I might well be wrong.
but it nicely fixes the problem for me, and actually, you don't need
"at least N/2 pages". The size of the allocations hardly matters, just
the amount of allocations we did. Since kvm does some small
vmalloc allocations, that may be the reason for we triggering it.
next prev parent reply other threads:[~2008-10-28 21:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-28 22:55 [PATCH] regression: vmalloc easily fail Glauber Costa
2008-10-28 21:03 ` Avi Kivity
2008-10-28 21:09 ` Glauber Costa [this message]
2008-10-28 21:22 ` Matias Zabaljauregui
2008-10-28 21:22 ` Roland Dreier
2008-10-28 21:42 ` Arjan van de Ven
2008-10-28 22:03 ` Roland Dreier
2008-10-28 23:29 ` Nick Piggin
2008-10-29 6:28 ` Avi Kivity
2008-10-29 9:48 ` Glauber Costa
2008-10-29 10:11 ` Nick Piggin
2008-10-29 10:29 ` Avi Kivity
2008-10-29 10:43 ` Nick Piggin
2008-10-29 22:07 ` Glauber Costa
2008-10-30 1:53 ` Nick Piggin
2008-10-30 4:49 ` Nick Piggin
2008-10-30 11:28 ` Glauber Costa
2008-10-31 7:16 ` Nick Piggin
2008-11-04 17:51 ` Glauber Costa
2008-11-05 0:21 ` Glauber Costa
2008-10-30 16:46 ` Matt Mackall
2008-10-30 18:04 ` Glauber Costa
2008-10-31 2:59 ` Nick Piggin
2008-11-07 20:37 ` Glauber Costa
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=20081028210947.GA4269@poweredge.glommer \
--to=glommer@redhat.com \
--cc=aliguori@codemonkey.ws \
--cc=avi@redhat.com \
--cc=jeremy@goop.org \
--cc=krzysztof.h1@poczta.fm \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox