Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753799AbYJ1U66 (ORCPT ); Tue, 28 Oct 2008 16:58:58 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753252AbYJ1U6t (ORCPT ); Tue, 28 Oct 2008 16:58:49 -0400 Received: from mx2.redhat.com ([66.187.237.31]:47650 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753210AbYJ1U6s (ORCPT ); Tue, 28 Oct 2008 16:58:48 -0400 From: Glauber Costa To: linux-kernel@vger.kernel.org Cc: kvm@vger.kernel.org, avi@redhat.com, aliguori@codemonkey.ws, npiggin@suse.de, Jeremy Fitzhardinge , Krzysztof Helt Subject: [PATCH] regression: vmalloc easily fail. Date: Tue, 28 Oct 2008 20:55:13 -0200 Message-Id: <1225234513-3996-1-git-send-email-glommer@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1267 Lines: 39 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. Signed-off-by: Glauber Costa Cc: Jeremy Fitzhardinge Cc: Krzysztof Helt --- mm/vmalloc.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 0365369..a33b0d1 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -363,7 +363,7 @@ retry: } 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) -- 1.5.6.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/