From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2F7VWl8028036 for ; Wed, 15 Mar 2006 02:31:33 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2F7VXdf139512 for ; Wed, 15 Mar 2006 02:31:33 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2F7VXHO012507 for ; Wed, 15 Mar 2006 02:31:33 -0500 Date: Tue, 14 Mar 2006 23:30:46 -0800 From: Nishanth Aravamudan Subject: Re: BUG in x86_64 hugepage support Message-ID: <20060315073046.GA5620@us.ibm.com> References: <20060315043544.GD5526@us.ibm.com> <200603150708.k2F78wg12642@unix-os.sc.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200603150708.k2F78wg12642@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 [23:08:57 -0800], Chen, Kenneth W wrote: > Nishanth Aravamudan wrote on Tuesday, March 14, 2006 8:36 PM > > > 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. > > Forget about preserving _PAGE_PSE BIT, It won't work. I just realized that > _PAGE_PROTNONE clashes with _PAGE_PSE (both use bit 7). Still thinking ... And here I was rather proud of the following patch :) I figured, if we know that we're dealing with a hugepage pte, then we probably can set _PAGE_PSE in newprot, no? This fixes the BUGs here, but may have side affects I'm unaware of (and I was unable to test on an i386 kernel, since all of a sudden -mm decided to stop building with Ubuntu's biarch gcc -- another topic altogether). Here's the patch I used. Description: We currently fail mprotect testing in libhugetlbfs because the PSE bit in the hugepage PTEs gets unset. In the case where we know that a filled hugetlb PTE is going to have its protection changed, make sure it stays a hugetlb PTE by setting the PSE bit in the new protection flags. Signed-off-by: Nishanth Aravamudan diff -urpN 2.6.16-rc6-mm1/mm/hugetlb.c 2.6.16-rc6-mm1-dev/mm/hugetlb.c --- 2.6.16-rc6-mm1/mm/hugetlb.c 2006-03-14 22:49:44.000000000 -0800 +++ 2.6.16-rc6-mm1-dev/mm/hugetlb.c 2006-03-14 22:51:31.000000000 -0800 @@ -740,6 +740,7 @@ void hugetlb_change_protection(struct vm continue; if (!pte_none(*ptep)) { pte = huge_ptep_get_and_clear(mm, address, ptep); + pgprot_val(newprot) |= _PAGE_PSE; pte = pte_modify(pte, newprot); set_huge_pte_at(mm, address, ptep, pte); lazy_mmu_prot_update(pte); -- 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