linux-kernel - Re: [discuss] 2.6.19-rc6: known regressions (v4)

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: <20061123110930.abc4fd9a.akpm@osdl.org>
Date:	Thu, 23 Nov 2006 11:09:30 -0800
From:	Andrew Morton <akpm@...l.org>
To:	mel@...net.ie (Mel Gorman)
Cc:	Andre Noll <maan@...temlinux.org>, Andi Kleen <ak@...e.de>,
	discuss@...-64.org, Adrian Bunk <bunk@...sta.de>,
	Linus Torvalds <torvalds@...l.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	David Rientjes <rientjes@...washington.edu>
Subject: Re: [discuss] 2.6.19-rc6: known regressions (v4)

On Thu, 23 Nov 2006 12:01:41 +0000
mel@...net.ie (Mel Gorman) wrote:

> find_min_pfn_for_node() and find_min_pfn_with_active_regions() both depend
> on a sorted early_node_map[]. However, sort_node_map() is being called after
> fin_min_pfn_with_active_regions() in free_area_init_nodes(). In most cases,
> this is ok, but on at least one x86_64, the SRAT table caused the E820 ranges
> to be registered out of order. This gave the wrong values for the min PFN
> range resulting in some pages not being initialised.
> 
> This patch sorts the early_node_map in find_min_pfn_for_node(). It has
> been boot tested on x86, x86_64, ppc64 and ia64.
> 
> Signed-off-by: Mel Gorman <mel@....ul.ie>
> 
> diff -rup linux-2.6.19-rc6-clean/mm/page_alloc.c linux-2.6.19-rc6-sort_in_find_min/mm/page_alloc.c
> --- linux-2.6.19-rc6-clean/mm/page_alloc.c	2006-11-15 20:03:40.000000000 -0800
> +++ linux-2.6.19-rc6-sort_in_find_min/mm/page_alloc.c	2006-11-23 02:23:57.000000000 -0800
> @@ -2612,6 +2612,9 @@ unsigned long __init find_min_pfn_for_no
>  {
>  	int i;
>  
> +	/* Regions in the early_node_map can be in any order */
> +	sort_node_map();
> +
>  	/* Assuming a sorted map, the first range found has the starting pfn */
>  	for_each_active_range_index_in_nid(i, nid)
>  		return early_node_map[i].start_pfn;
> @@ -2680,9 +2683,6 @@ void __init free_area_init_nodes(unsigne
>  			max(max_zone_pfn[i], arch_zone_lowest_possible_pfn[i]);
>  	}
>  
> -	/* Regions in the early_node_map can be in any order */
> -	sort_node_map();
> -
>  	/* Print out the zone ranges */
>  	printk("Zone PFN ranges:\n");
>  	for (i = 0; i < MAX_NR_ZONES; i++)

Doesn't this mean that we can sort that map multiple times?

Seems a bit ... ungainly?
-
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/