On Wed 24-02-21 19:10:42, Muchun Song wrote: > On Wed, Feb 24, 2021 at 5:43 PM Michal Hocko <mhocko@xxxxxxxx> wrote: > > > > On Tue 23-02-21 13:55:44, Mike Kravetz wrote: > > > Gerald Schaefer reported a panic on s390 in hugepage_subpool_put_pages() > > > with linux-next 5.12.0-20210222. > > > Call trace: > > > hugepage_subpool_put_pages.part.0+0x2c/0x138 > > > __free_huge_page+0xce/0x310 > > > alloc_pool_huge_page+0x102/0x120 > > > set_max_huge_pages+0x13e/0x350 > > > hugetlb_sysctl_handler_common+0xd8/0x110 > > > hugetlb_sysctl_handler+0x48/0x58 > > > proc_sys_call_handler+0x138/0x238 > > > new_sync_write+0x10e/0x198 > > > vfs_write.part.0+0x12c/0x238 > > > ksys_write+0x68/0xf8 > > > do_syscall+0x82/0xd0 > > > __do_syscall+0xb4/0xc8 > > > system_call+0x72/0x98 > > > > > > This is a result of the change which moved the hugetlb page subpool > > > pointer from page->private to page[1]->private. When new pages are > > > allocated from the buddy allocator, the private field of the head > > > page will be cleared, but the private field of subpages is not modified. > > > Therefore, old values may remain. > > > > Very interesting. I have expected that the page->private would be in a > > reasonable state when allocated. On the other hand hugetlb doesn't do > > __GFP_COMP so tail pages are not initialized by the allocator. > > It seems that the buddy allocator does not initialize the private field > of the tail page even when we specify __GFP_COMP. Yes it doesn't. What I meant to say is that even if it did a lack of __GFP_COMP would result in not doing so. I do not remember why hugetlb doesn't use __GFP_COMP but I believe this was never the case. -- Michal Hocko SUSE Labs
