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: <a38fb457-c0e8-4089-a31a-ac59d06a796f@suse.cz>
Date: Mon, 9 Feb 2026 12:17:36 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: "David Hildenbrand (Arm)" <david@...nel.org>,
 Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>, linux-mm@...ck.org
Cc: akpm@...ux-foundation.org, surenb@...gle.com, mhocko@...e.com,
 jackmanb@...gle.com, hannes@...xchg.org, ziy@...dia.com, 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 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?).