linux-kernel - Re: [PATCH v3] mm/page_alloc: clear page->private in free_pages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CD2D5EFD-53FC-4E0B-B7B8-023495867C65@nvidia.com>
Date: Mon, 09 Feb 2026 11:05:09 -0500
From: Zi Yan <ziy@...dia.com>
To: "David Hildenbrand (Arm)" <david@...nel.org>
Cc: Vlastimil Babka <vbabka@...e.cz>,
 Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>, linux-mm@...ck.org,
 akpm@...ux-foundation.org, surenb@...gle.com, mhocko@...e.com,
 jackmanb@...gle.com, hannes@...xchg.org, npiggin@...il.com,
 linux-kernel@...r.kernel.org, kasong@...cent.com, hughd@...gle.com,
 chrisl@...nel.org, ryncsn@...il.com, stable@...r.kernel.org,
 willy@...radead.org
Subject: Re: [PATCH v3] mm/page_alloc: clear page->private in
 free_pages_prepare()

On 9 Feb 2026, at 11:03, David Hildenbrand (Arm) wrote:

> On 2/9/26 17:00, Zi Yan wrote:
>> On 9 Feb 2026, at 10:46, David Hildenbrand (Arm) wrote:
>>
>>> On 2/9/26 12:17, Vlastimil Babka wrote:
>>>>
>>>> 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.
>
> Yes, it's designed like that; because that check here caught it during development :)
>
>>
>>>
>>> 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?
>
> I don't understand the question, can you elaborate?

You said,
“BTW, I wonder whether we should bring that check back for non-device folios.”

I thought you know why device folio needs to keep ->private not cleared during
split.


> I asked Balbir why the check was dropped in the first place.


Best Regards,
Yan, Zi