linux-kernel - Re: [PATCH v4, part3 13/41] mm/ARM: prepare for removing num_physpages and simplify mem

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: <20130419165429.GA14496@n2100.arm.linux.org.uk>
Date:	Fri, 19 Apr 2013 17:54:29 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Jiang Liu <liuj97@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Jiang Liu <jiang.liu@...wei.com>,
	David Rientjes <rientjes@...gle.com>,
	Wen Congyang <wency@...fujitsu.com>,
	Mel Gorman <mgorman@...e.de>, Minchan Kim <minchan@...nel.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Michal Hocko <mhocko@...e.cz>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
	David Howells <dhowells@...hat.com>,
	Mark Salter <msalter@...hat.com>,
	Jianguo Wu <wujianguo@...wei.com>, linux-mm@...ck.org,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v4, part3 13/41] mm/ARM: prepare for removing
	num_physpages and simplify mem_init()

On Sat, Apr 06, 2013 at 10:32:12PM +0800, Jiang Liu wrote:
> Prepare for removing num_physpages and simplify mem_init().
> 
> Signed-off-by: Jiang Liu <jiang.liu@...wei.com>
> Cc: Russell King <linux@....linux.org.uk>
> Cc: Catalin Marinas <catalin.marinas@....com>
> Cc: Will Deacon <will.deacon@....com>
> Cc: linux-arm-kernel@...ts.infradead.org
> Cc: linux-kernel@...r.kernel.org
> ---
>  arch/arm/mm/init.c |   47 ++---------------------------------------------
>  1 file changed, 2 insertions(+), 45 deletions(-)
> 
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index add4fcb..7a911d1 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -582,9 +582,6 @@ static void __init free_highpages(void)
>   */
>  void __init mem_init(void)
>  {
> -	unsigned long reserved_pages, free_pages;
> -	struct memblock_region *reg;
> -	int i;
>  #ifdef CONFIG_HAVE_TCM
>  	/* These pointers are filled in on TCM detection */
>  	extern u32 dtcm_end;
> @@ -605,47 +602,7 @@ void __init mem_init(void)
>  
>  	free_highpages();
>  
> -	reserved_pages = free_pages = 0;
> -
> -	for_each_bank(i, &meminfo) {
> -		struct membank *bank = &meminfo.bank[i];
> -		unsigned int pfn1, pfn2;
> -		struct page *page, *end;
> -
> -		pfn1 = bank_pfn_start(bank);
> -		pfn2 = bank_pfn_end(bank);
> -
> -		page = pfn_to_page(pfn1);
> -		end  = pfn_to_page(pfn2 - 1) + 1;
> -
> -		do {
> -			if (PageReserved(page))
> -				reserved_pages++;
> -			else if (!page_count(page))
> -				free_pages++;
> -			page++;
> -		} while (page < end);
> -	}
> -
> -	/*
> -	 * Since our memory may not be contiguous, calculate the
> -	 * real number of pages we have in this system
> -	 */
> -	printk(KERN_INFO "Memory:");
> -	num_physpages = 0;
> -	for_each_memblock(memory, reg) {
> -		unsigned long pages = memblock_region_memory_end_pfn(reg) -
> -			memblock_region_memory_base_pfn(reg);
> -		num_physpages += pages;
> -		printk(" %ldMB", pages >> (20 - PAGE_SHIFT));
> -	}
> -	printk(" = %luMB total\n", num_physpages >> (20 - PAGE_SHIFT));
> -
> -	printk(KERN_NOTICE "Memory: %luk/%luk available, %luk reserved, %luK highmem\n",
> -		nr_free_pages() << (PAGE_SHIFT-10),
> -		free_pages << (PAGE_SHIFT-10),
> -		reserved_pages << (PAGE_SHIFT-10),
> -		totalhigh_pages << (PAGE_SHIFT-10));
> +	mem_init_print_info(NULL);

I'm concerned about this.  We explicitly do not use the memblock information
when walking the memory above for the reserved/free pages because memblock
merges the various banks of memory together - and those may cross sparsemem
boundaries.  Any crossing of the sparsemem boundaries needs the struct page
pointer to be re-evaluated because it can be part of a different array of
such things.

Where's the rest of the patches?
--
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/