From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from caramon.arm.linux.org.uk ([78.32.30.218]:36609 "EHLO caramon.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752887Ab0DLVLu (ORCPT ); Mon, 12 Apr 2010 17:11:50 -0400 Date: Mon, 12 Apr 2010 22:11:15 +0100 From: Russell King - ARM Linux Subject: Re: [PATCH] arm: mm: Don't free prohibited memmap entries Message-ID: <20100412211115.GX3048@n2100.arm.linux.org.uk> References: <> <1270506861-14461-1-git-send-email-mbohan@codeaurora.org> <20100406220817.GE12831@n2100.arm.linux.org.uk> <4BBBD2CD.2010205@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BBBD2CD.2010205@codeaurora.org> Sender: linux-arm-msm-owner@vger.kernel.org List-ID: To: Michael Bohan Cc: mel@csn.ul.ie, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Michael Bohan On Tue, Apr 06, 2010 at 05:33:17PM -0700, Michael Bohan wrote: > On 4/6/2010 3:08 PM, Russell King - ARM Linux wrote: >> 1. are you enabling ARCH_HAS_HOLES_MEMORYMODEL ? >> > > Yes, although this does not impact the problem I'm dealing with. That > option is only used for /proc/pagetypeinfo currently. It would be good > if we could consolidate ARCH_HAS_HOLES_MEMORYMODEL and HOLES_IN_ZONE, > but that may be out of scope for this change. > >> 2. where does it try to access these page structs without trying >> pfn_valid() to check whether a page struct exists first? >> > > The specific piece of code that is causing crashes in my scenario is in > vm/page_alloc.c:move_freepages(), called from move_freepages_block(). > The code in move_freepages_block aligns the end_pfn to the closest page > block, which may take us to invalid memmap entries. > > The macro that conditionally saves us in this case is the > pfn_valid_within(), called from move_freepages(). If HOLES_IN_ZONE is > configured, this option calls down to pfn_valid() to make sure the page > has a valid memmap entry. There are likely other cases where this is an > issue as well that I haven't run into. Well, there's two ways to look at this - either you should ensure that memory is available up to MAX_ORDER_NR_PAGES, possibly reducing this number of that's necessary to achive this. Or, we need to have ARCH_HAS_HOLES_MEMORYMODEL needs to select HOLES_IN_ZONE so we get proper checking of PFNs - maybe conditional on MSM. I think most users of ARCH_HAS_HOLES_MEMORYMODEL align memory to a power-of-two amount of memory, and so MAX_ORDER_NR_PAGES doesn't cause them a problem.