From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] regression: vmalloc easily fail. Date: Wed, 29 Oct 2008 08:28:04 +0200 Message-ID: <49080274.4040905@redhat.com> References: <1225234513-3996-1-git-send-email-glommer@redhat.com> <20081028232944.GA3759@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Glauber Costa , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, aliguori@codemonkey.ws, Jeremy Fitzhardinge , Krzysztof Helt To: Nick Piggin Return-path: Received: from mx2.redhat.com ([66.187.237.31]:36888 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752020AbYJ2G2J (ORCPT ); Wed, 29 Oct 2008 02:28:09 -0400 In-Reply-To: <20081028232944.GA3759@wotan.suse.de> Sender: kvm-owner@vger.kernel.org List-ID: Nick Piggin wrote: > Right... that was to add a guard page like the old vmalloc allocator. > vmallocs still add their extra page too, so most of them will have > a 2 page guard area, but I didn't think this would hurt significantly. > > I'm not against the patch, but I wonder exactly what is filling it up > and how? (can you look at the vmalloc proc function to find out? Maybe we're allocating two guard pages, but freeing only one? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.