Re: BUG in x86_64 hugepage support

Nishanth Aravamudan
2006-03-15T04:36:31Z

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.