> On Apr 4, 2024, at 19:13, Oscar Salvador <osalvador@xxxxxxx> wrote: > > On Wed, Apr 03, 2024 at 10:17:45PM +0100, Matthew Wilcox wrote: >> I think hugetlb is being unnecessarily paranoid here, tbh. Or maybe >> this part is just badly structured; if we're allocating a hugetlb folio, >> it should be fine for its refcount to be temporarily elevated by someone >> else. Not sure I can figure out what's going on in >> alloc_and_dissolve_hugetlb_folio() though. > > AFAICR, the problem comes when we need to remap the pages for vmemmap > optimization [1]. > So, IIUC: > > 1) if someone comes around and grabs a refcount (say something doing > speculative stuff) > 2) we do the remapping > 3) that someone who took the refcount, now does a put_page() > 4) vmemmap no longer points to the old page but the new one, meaning > that that 'put_page()' is done on the wrong page. > > @Munchun: Did I get this right? Right. But let me clarify this again. We need to keep the content of the physical page constant throughout the processing of HVO (i.g. between the copying of head vmemmap page and remapping of it). Zero-referenced page could prevent others from updating the content of the page structs. > > [1] https://lore.kernel.org/linux-mm/YupRjWRiz4lPo+y7@FVFYT0MHHV2J/ Yes, I've also pointed it out here. Thanks. > > > -- > Oscar Salvador > SUSE Labs
