From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2F4aV7H017000 for ; Tue, 14 Mar 2006 23:36:31 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2F4XdLl211516 for ; Tue, 14 Mar 2006 21:33:39 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k2F4aUA4000602 for ; Tue, 14 Mar 2006 21:36:30 -0700 Date: Tue, 14 Mar 2006 20:35:44 -0800 From: Nishanth Aravamudan Subject: Re: BUG in x86_64 hugepage support Message-ID: <20060315043544.GD5526@us.ibm.com> References: <20060315012000.GC5526@us.ibm.com> <200603150403.k2F43Kg10964@unix-os.sc.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200603150403.k2F43Kg10964@unix-os.sc.intel.com> Sender: owner-linux-mm@kvack.org Return-Path: To: "Chen, Kenneth W" Cc: agl@us.ibm.com, david@gibson.dropbear.id.au, ak@suse.de, linux-mm@kvack.org, discuss@x86-64.org List-ID: On 14.03.2006 [20:03:20 -0800], Chen, Kenneth W wrote: > Nishanth Aravamudan wrote on Tuesday, March 14, 2006 5:20 PM > > While doing some testing of libhugetlbfs, I ran into the following > > BUGs on my x86_64 box when checking mprotect with hugepages (running > > make func in libhugetlbfs is all it took here) (distro is Ubuntu > > Dapper, runs 32-bit userspace). > > > > So, the first &= results in the lower 11 bits of pte_val(pte) being > > all 0s. By my analysis, this is the problem, pte_modify() on x86_64 > > is clearing the bits we check to see if a pte is a hugetlb one. To > > see if this might be an accurate analysis, I modified _PAGE_CHG_MASK > > as follows: > > > > -#define _PAGE_CHG_MASK (PTE_MASK | _PAGE_ACCESSED | _PAGE_DIRTY) > > +#define _PAGE_CHG_MASK (PTE_MASK | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_PSE | _PAGE_PRESENT) > > > > That is, forcing the bits we care about to get set in pte_modify(). > > This removed the BUG()s I was seeing in our testing. > > I think your analysis looked correct. Though I don't think you want > to add _PAGE_PRESENT to _PAGE_CHG_MASK. The reason being newprot > suppose to have correct present bit (based on what the new protection > is) and it will be or'ed to form new pte. Thanks for the response! > I think _PAGE_PSE bit should be in _PAGE_CHG_MASK. I can try a kernel with just the _PAGE_PSE bit added to _PAGE_CHG_MASK and see if that helps. I think it will still BUG() in my case, however, as __LARGE_PTE is 10000001, so only setting the 8th bit will be insufficient. So maybe there is also something wrong with what is being generated by pgprot_val(newprot)? I will try adding some more debugging output to see what is happening in pte_modify. Thanks, Nish -- Nishanth Aravamudan IBM Linux Technology Center -- 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