From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx165.postini.com [74.125.245.165]) by kanga.kvack.org (Postfix) with SMTP id A8FDE6B0032 for ; Wed, 24 Apr 2013 19:40:10 -0400 (EDT) Received: by mail-da0-f46.google.com with SMTP id x4so574332daj.33 for ; Wed, 24 Apr 2013 16:40:09 -0700 (PDT) Message-ID: <51786D52.1080509@gmail.com> Date: Thu, 25 Apr 2013 07:40:02 +0800 From: Simon Jeons MIME-Version: 1.0 Subject: Re: mm: BUG in do_huge_pmd_wp_page References: <51559150.3040407@oracle.com> <20130410080202.GB21292@blaptop> <517861E0.7030801@zytor.com> In-Reply-To: <517861E0.7030801@zytor.com> Content-Type: multipart/alternative; boundary="------------070208070203030706080106" Sender: owner-linux-mm@kvack.org List-ID: To: "H. Peter Anvin" Cc: Minchan Kim , Sasha Levin , "Kirill A. Shutemov" , Andrew Morton , David Rientjes , Andrea Arcangeli , Mel Gorman , Dave Jones , linux-mm , "linux-kernel@vger.kernel.org" This is a multi-part message in MIME format. --------------070208070203030706080106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Peter, On 04/25/2013 06:51 AM, H. Peter Anvin wrote: > On 04/10/2013 01:02 AM, Minchan Kim wrote: >> When I am looking at the code, I was wonder about the logic of GHZP(aka, >> get_huge_zero_page) reference handling. The logic depends on that page >> allocator never alocate PFN 0. >> >> Who makes sure it? What happens if allocator allocates PFN 0? >> I don't know all of architecture makes sure it. >> You investigated it for all arches? >> > This isn't manifest, right? At least on x86 we should never, ever > allocate PFN 0. I see in memblock_trim_memory(): start = round_up(orig_start, align); here align is PAGE_SIZE, so the dump of zone ranges in my machine is [ 0.000000] DMA [mem 0x00001000-0x00ffffff]. Why PFN 0 is not used? just for align? > > -hpa > > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org --------------070208070203030706080106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi Peter,
On 04/25/2013 06:51 AM, H. Peter Anvin wrote:

On 04/10/2013 01:02 AM, Minchan Kim wrote:

When I am looking at the code, I was wonder about the logic of GHZP(aka,
get_huge_zero_page) reference handling. The logic depends on that page
allocator never alocate PFN 0.

Who makes sure it? What happens if allocator allocates PFN 0?
I don't know all of architecture makes sure it.
You investigated it for all arches?

This isn't manifest, right?  At least on x86 we should never, ever
allocate PFN 0.

I see in memblock_trim_memory(): start = round_up(orig_start, align); here align is PAGE_SIZE, so the dump of zone ranges in my machine is [ 0.000000] DMA [mem 0x00001000-0x00ffffff]. Why PFN 0 is not used? just for align?


	-hpa


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

--------------070208070203030706080106-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org