On Mon, Jan 10, 2011 at 06:29:29PM -0800, Hugh Dickins wrote: > On Mon, Jan 10, 2011 at 5:57 PM, Andrea Arcangeli <aarcange@xxxxxxxxxx> wrote: > > On Mon, Jan 10, 2011 at 04:55:53PM -0800, Hugh Dickins wrote: > >> If you configure THP in addition to HUGETLB_PAGE on x86_32 without PAE, > >> the p?d-folding works out that munlock_vma_pages_range() can crash to > >> follow_page()'s pud_huge() BUG_ON(flags & FOLL_GET): it needs the same > >> VM_HUGETLB check already there on the pmd_huge() line. Conveniently, > >> openSUSE provides a "blogd" which tests this out at startup! > > > > How is THP related to this? pud_trans_huge doesn't exist, if pud_huge > > is true, vma is already guaranteed to belong to hugetlbfs without > > requiring the additional check. > > THP puts in pmds that are huge. In this configuration the "folding" is > such that the puds are the pmds. So the pud_huge test passes and > the BUG_ON hits. I hope I've explained that correctly, agreed that > it's confusing! > > > > > I added the check to pmd_huge already, there it is needed, but for > > pud_huge it isn't as far as I can tell. > > Crashing on that BUG_ON suggests otherwise ;) I think I see what you mean, pgd=pud=pmd with 2 levels only, but if pud_huge can return 1 on x86_32 without PAE, that sounds like an architectural bug to me. Why can't pud_huge simply return 0 for x86_32? Any other place dealing with hugepages and calling pud_huge on x86 noPAE would be at risk, otherwise, no? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>