Re: [PATCH v4 1/7] mm/zone_device: Add order argument to folio_free callback

On 12 Jan 2026, at 14:28, Jason Gunthorpe wrote:

On Mon, Jan 12, 2026 at 01:55:18PM -0500, Zi Yan wrote:

quoted

quoted

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 :\

quoted

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().

quoted

quoted

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.

quoted

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