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

[Zi Yan]

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.

Best Regards,
Yan, Zi