From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NVoL1-0007gL-Mq for qemu-devel@nongnu.org; Fri, 15 Jan 2010 10:43:51 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NVoL0-0007f0-NF for qemu-devel@nongnu.org; Fri, 15 Jan 2010 10:43:51 -0500 Received: from [199.232.76.173] (port=52016 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NVoL0-0007ev-KX for qemu-devel@nongnu.org; Fri, 15 Jan 2010 10:43:50 -0500 Received: from are.twiddle.net ([75.149.56.221]:32942) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NVoL0-00073j-7r for qemu-devel@nongnu.org; Fri, 15 Jan 2010 10:43:50 -0500 Received: from anchor.twiddle.home (anchor.twiddle.home [172.31.0.4]) by are.twiddle.net (Postfix) with ESMTPSA id 23B97B91 for ; Fri, 15 Jan 2010 07:43:48 -0800 (PST) Message-ID: <4B508D34.70304@twiddle.net> Date: Fri, 15 Jan 2010 07:43:48 -0800 From: Richard Henderson MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] linux-user: Align mmap memory to the target page size. References: <20100115011604.DCB1CB93@are.twiddle.net> In-Reply-To: <20100115011604.DCB1CB93@are.twiddle.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 01/14/2010 04:38 PM, Richard Henderson wrote: > Previously, mmap_find_vma could return addresses not properly aligned > to the target page size. This of course led to all sorts of odd > problems down the road. > > The trivial fix, to simply reject the unaligned address and continue > searching the address space by increments of one page, is not a good > idea when there's a 64-bit address space involved. The kernel may well > continue to return the last available address which we've already > rejected while we search upward from e.g. 2**42 from 2**64. > > This patch uses a more complex search algorithm that takes the result > of the previous allocation into account. We normally search upward, > but notice 2 consecutive results and start searching downward instead. I've failed to take guest_base into account properly; my testing happened to have guest_base = 0. New patch to follow. r~