On 12 Jan 2026, at 14:28, Jason Gunthorpe wrote: > On Mon, Jan 12, 2026 at 01:55:18PM -0500, Zi Yan wrote: >>> That's different, I am talking about reaching 0 because it has been >>> freed, meaning there are no external pointers to it. >>> >>> Further, when a page is frozen page_ref_freeze() takes in the number >>> of references the caller has ownership over and it doesn't succeed if >>> there are stray references elsewhere. >>> >>> This is very important because the entire operating model of split >>> only works if it has exclusive locks over all the valid pointers into >>> that page. >>> >>> Spurious refcount failures concurrent with split cannot be allowed. >>> >>> I don't see how pointing at __folio_freeze_and_split_unmapped() can >>> justify this series. >>> >> >> But from anyone looking at the folio state, refcount == 0, compound_head >> is set, they cannot tell the difference. > > This isn't reliable, nothing correct can be doing it :\ > >> If what you said is true, why is free_pages_prepare() needed? No one >> should touch these free pages. Why bother resetting these states. > > ? that function does alot of stuff, thinks like uncharging the cgroup > should obviously happen at free time. > > What part of it are you looking at?
page[1].flags.f &= ~PAGE_FLAGS_SECOND. It clears folio->order. free_tail_page_prepare() clears ->mapping, which is TAIL_MAPPING, and compound_head at the end. page->flags.f &= ~PAGE_FLAGS_CHECK_AT_PREP. It clears PG_head for compound pages. These three parts undo prep_compound_page(). > >>> You can't refcount a folio out of nothing. It has to come from a >>> memory location that already is holding a refcount, and then you can >>> incr it. >> >> Right. There is also no guarantee that all code is correct and follows >> this. > > Let's concretely point at things that have a problem please. > >> My point here is that calling prep_compound_page() on a compound page >> does not follow core MM’s conventions. > > Maybe, but that doesn't mean it isn't the right solution.. In current nouveau code, ->free_folios is used holding the freed folio. In nouveau_dmem_page_alloc_locked(), the freed folio is passed to zone_device_folio_init(). If the allocated folio order is different from the freed folio order, I do not know how you are going to keep track of the rest of the freed folio. Of course you can implement a buddy allocator there. If this still does not convince you that overwriting an existing compound page with a different order configuration is a bad idea, feel free to do whatever you think it is right. Best Regards, Yan, Zi
