[PATCH] arm: mm: Don't free prohibited memmap entries
Russell King - ARM Linux
linux at arm.linux.org.uk
Mon Apr 12 17:11:15 EDT 2010
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.
More information about the linux-arm-kernel
mailing list