> PF_NO_COMPOUND for PG_reserved assumes we don't use PG_reserved for > compound pages. And we generally don't. But during allocation of > gigantic pages we set PG_head before clearing PG_reserved and > __ClearPageReserved() steps on the VM_BUG_ON_PAGE(). > > The fix is trivial: set PG_head after PG_reserved. > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> > Reported-by: Sasha Levin <sasha.levin@xxxxxxxxxx> > --- Acked-by: Hillf Danton <hillf.zj@xxxxxxxxxxxxxxx> > > Andrew, this patch can be folded into "page-flags: define PG_reserved behavior on compound pages". > > --- > mm/hugetlb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index 6ecf61ffa65d..bd3f3e20313b 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -1258,8 +1258,8 @@ static void prep_compound_gigantic_page(struct page *page, unsigned int order) > > /* we rely on prep_new_huge_page to set the destructor */ > set_compound_order(page, order); > - __SetPageHead(page); > __ClearPageReserved(page); > + __SetPageHead(page); > for (i = 1; i < nr_pages; i++, p = mem_map_next(p, page, i)) { > /* > * For gigantic hugepages allocated through bootmem at > -- > 2.5.3 > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>