linux-kernel - Re: [PATCH] Fix crash with FLAT_MEMORY and ARCH_PFN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071218135828.GB24917@csn.ul.ie>
Date:	Tue, 18 Dec 2007 13:58:28 +0000
From:	Mel Gorman <mel@....ul.ie>
To:	Thomas Bogendoerfer <tsbogend@...ha.franken.de>
Cc:	linux-kernel@...r.kernel.org, Bob Picco <bob.picco@...com>,
	Dave Hansen <haveblue@...ibm.com>,
	Andy Whitcroft <apw@...dowen.org>, Andi Kleen <ak@....de>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mackerras <paulus@...ba.org>,
	Keith Mannthey <kmannth@...il.com>,
	"Luck, Tony" <tony.luck@...el.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Yasunori Goto <y-goto@...fujitsu.com>,
	akpm@...ux-foundation.org, Linus Torvalds <torvalds@...l.org>,
	ralf@...ux-mips.org
Subject: Re: [PATCH] Fix crash with FLAT_MEMORY and ARCH_PFN_OFFSET != 0

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@...ha.franken.de>
> ---
> 
>  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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/