On Mon, Aug 21, 2023 at 08:13:00PM -0700, Mike Kravetz wrote:
> On 08/16/23 16:11, Matthew Wilcox (Oracle) wrote:
> > We can use a bit in page[1].flags to indicate that this folio belongs
> > to hugetlb instead of using a value in page[1].dtors. That lets
> > folio_test_hugetlb() become an inline function like it should be.
> > We can also get rid of NULL_COMPOUND_DTOR.
>
> Not 100% sure yet, but I suspect this patch/series causes the following
> BUG in today's linux-next. I can do a deeper dive tomorrow.
>
> # echo 1 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
> # echo 0 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
>
> [ 352.631099] page:ffffea0007a30000 refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x1e8c00
> [ 352.633674] head:ffffea0007a30000 order:8 entire_mapcount:0 nr_pages_mapped:0 pincount:0
order 8? Well, that's exciting. This is clearly x86, so it should be
order 9. Did we mistakenly clear bit 0 of tail->flags?
Oh. Oh yes, we do.
__update_and_free_hugetlb_folio:
for (i = 0; i < pages_per_huge_page(h); i++) {
subpage = folio_page(folio, i);
subpage->flags &= ~(1 << PG_locked | 1 << PG_error |
1 << PG_referenced | 1 << PG_dirty |
1 << PG_active | 1 << PG_private |
1 << PG_writeback);
}
locked PF_NO_TAIL
error PF_NO_TAIL
referenced PF_HEAD
dirty PF_HEAD
active PF_HEAD
private PF_ANY
writeback PF_NO_TAIL
So it seems to me there's no way to set any of these bits other than
PG_private. And, well, you control PG_private in hugetlbfs. Do you
ever set it on tail pages?
I think you can remove this entire loop and be happy?
