Re: [PATCH v3] mm/page_alloc: clear page->private in free_pages_prepare()

From: Zi Yan

Date: Mon Feb 09 2026 - 11:00:55 EST


On 9 Feb 2026, at 10:46, David Hildenbrand (Arm) wrote:

> On 2/9/26 12:17, Vlastimil Babka wrote:
>> On 2/7/26 23:08, David Hildenbrand (Arm) wrote:
>>>>
>>>> -               /*
>>>> -                * page->private should not be set in tail pages. Fix up
>>>> and warn once
>>>> -                * if private is unexpectedly set.
>>>> -                */
>>>> -               if (unlikely(new_folio->private)) {
>>>> -                       VM_WARN_ON_ONCE_PAGE(true, new_head);
>>>> -                       new_folio->private = NULL;
>>>> -               }
>>>
>>> BTW, I wonder whether we should bring that check back for non-device folios.
>>
>> If the rule is now that when upon freeing in free_pages_prepare() we clear
>> private in the head page and not tail pages (where we expect the owner of
>> the page to do it), maybe that check for tail pages should be done in the
>> is_check_pages_enabled() part of free_pages_prepare().
>>
>> Or should the check be also in the split path because somebody can set a
>> tail private between allocation and split? (and not just inherit it from a
>> previous allocation that didn't clear it?).
>
> We ran into that check in the past, when folio->X overlayed page->private in a tail, and would actually have to be zeroed out.

Currently, _mm_id (_mm_ids) overlaps with page->private. At split time,
it should be MM_ID_DUMMY (0), so page->private should be 0 all time.

>
> So it should be part of this splitting code I think.

It is still better to have the check and fix in place. Why do we want to
skip device private folio?


Best Regards,
Yan, Zi