Re: [PATCH] Fix crash with FLAT_MEMORY and ARCH_PFN_OFFSET != 0

[Mel Gorman]

On (18/12/07 13:03), Thomas Bogendoerfer didst pronounce:
> When using FLAT_MEMORY and ARCH_PFN_OFFSET is not 0, the kernel
> crashes in memmap_init_zone(). This bug got introduced by
> commit c713216deebd95d2b0ab38fef8bb2361c0180c2d
> 

That commit is over a year old and it initially distressed me that it
would take this long to show up on a boot test. However, you said this was
to fix MIPS in a follow-on mail and I never made it use arch-independent
zone-sizing which is where CONFIG_ARCH_POPULATES_NODE_MAP comes from. Support
for arch-independent zone-sizing was added for MIPS on Nov 3rd 2007 by commit
cce335ae47e231398269fb05fa48e0e9cbf289e0 (relevant cc added) which is a much
more reasonable timeframe for catching this sort of problem. I believe the
real bug might be in there.

Can you post a full dmesg log with loglevel=8 so I can see what the layout
looks like? My aim is to find out why the start of your mem_map is not at
the start of node 0's mem_map which is what I generally expected with the
FLATMEM model.

Thanks.

> Signed-off-by: Thomas Bogendoerfer <tsbogend@xxxxxxxxxxxxxxxx>
> ---
> 
>  mm/page_alloc.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index b5a58d4..496f7f3 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3427,7 +3427,7 @@ static void __init_refok alloc_node_mem_map(struct pglist_data *pgdat)
>  		mem_map = NODE_DATA(0)->node_mem_map;
>  #ifdef CONFIG_ARCH_POPULATES_NODE_MAP
>  		if (page_to_pfn(mem_map) != pgdat->node_start_pfn)
> -			mem_map -= pgdat->node_start_pfn;
> +			mem_map -= (pgdat->node_start_pfn - ARCH_PFN_OFFSET);
>  #endif /* CONFIG_ARCH_POPULATES_NODE_MAP */
>  	}
>  #endif
> 

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/