On Wed, Apr 13, 2022 at 12:08:04PM -0700, Andrew Morton wrote: > On Wed, 13 Apr 2022 22:47:45 +0800 Muchun Song <songmuchun@xxxxxxxxxxxxx> wrote: > > > If the size of "struct page" is not the power of two but with the feature > > of minimizing overhead of struct page associated with each HugeTLB is > > enabled, then the vmemmap pages of HugeTLB will be corrupted after > > remapping (panic is about to happen in theory). But this only exists when > > !CONFIG_MEMCG && !CONFIG_SLUB on x86_64. However, it is not a conventional > > configuration nowadays. So it is not a real word issue, just the result > > of a code review. > > The patch does add a whole bunch of tricky junk to address something > which won't happen. How about we simply disable > CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP if (!CONFIG_MEMCG && > !CONFIG_SLUB)? > I'm afraid not. The size of 'struct page' also depends on LAST_CPUPID_NOT_IN_PAGE_FLAGS which could be defined when CONFIG_NODES_SHIFT or CONFIG_KASAN_SW_TAGS or CONFIG_NR_CPUS is configured with a large value. Then the size would be more than 64 bytes. Seems like the approach [1] is more simple and feasible, which also could prevent the users from doing unexpected configurations, however, it is objected by Masahiro. Shall we look back at the approach again? Thanks.
