Re: [PATCH v2] mm/migrate: rename PAGE_ migration flags to FOLIO_

[Matthew Wilcox]

On Wed, Mar 25, 2026 at 11:05:44AM -0400, Zi Yan wrote:
> On 25 Mar 2026, at 11:04, David Hildenbrand (Arm) wrote:
> 
> > On 3/25/26 16:00, Zi Yan wrote:
> >> On 25 Mar 2026, at 10:53, David Hildenbrand (Arm) wrote:
> >>
> >>> On 3/25/26 15:21, Zi Yan wrote:
> >>>>
> >>>>
> >>>> Hi David,
> >>>
> >>> Hi,
> >>>
> >>>>
> >>>> In terms of folio_change_private(), I did not think it is related to
> >>>> folio_{attach,detach}_private(), since the latter change folio refcount during
> >>>> the operation. If folio_change_private() is related to attach/detach,
> >>>> I imagine it would check folio refcount before touches ->private. But
> >>>> that is my interpretation.
> >>>
> >>> I mean, given that
> >>>
> >>> a) It's located in pagemap.h in between folio_attach_private() and
> >>> folio_detach_private()
> >>>
> >>> b) It clearly states that "The page must previously have had data
> >>> attached and the data must be detached before the folio will be freed."
> >>>
> >>> This is the wrong API to use?
> >>>
> >>> Sure, it sets folio->private but in different context.
> >>>
> >>> I can spot one user in mm/hugetlb.c, that likely also should not be
> >>> using this API, because there likely was no previous attach/detach.
> >>>
> >>>>
> >>>> BTW, do you know why we have set_page_private() but no folio_set_private()?
> >>>> I would suggest folio_set_private() if it exists.
> >>>
> >>> folio_set_private() sets ... PG_private. :)
> >>>
> >>> folio_test_private() checks PG_private and folio_get_private() returns
> >>> page->private.
> >>>
> >>> A cursed interface.
> >>
> >> Oh man. folio_get_private() should be renamed to folio_get_private_data(),
> >> so that we can have folio_set_private_data().
> >
> > Likely we should strive towards only using folio->private (and the API)
> > really for fs-private data (i.e., the pagemap.h interface), and add
> > proper custom members for all other use cases.
> >
> > For page->private it's a different discussion (requires more work I
> > guess, because there are many more use cases.
> >
> Makes sense to me.

The long term plan ...

 - Remove PG_private (we're pretty close actually).  That kills off
   folio_set_private() / folio_clear_private()
 - Reimplement folio_test_private().  It just checks whether folio->private is
   NULL.
 - Remove folio_get_private().  It's actually longer than just using
   folio->private and offers no advantages.