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? > > 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.. Jason
