From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org,josef@toxicpanda.com,akpm@linux-foundation.org
Subject: [to-be-updated] mm-page_alloc-clear-private-of-deferred-free-pages.patch removed from -mm tree
Date: Tue, 27 Oct 2026 20:06:38 -0700 [thread overview]
Message-ID: <20261028030638.9AA8B1F01828@smtp.kernel.org> (raw)
The quilt patch titled
Subject: mm/page_alloc: clear ->private of deferred free pages
has been removed from the -mm tree. Its filename was
mm-page_alloc-clear-private-of-deferred-free-pages.patch
This patch was dropped because an updated version will be issued
------------------------------------------------------
From: Josef Bacik <josef@toxicpanda.com>
Subject: mm/page_alloc: clear ->private of deferred free pages
Date: Tue, 27 Oct 2026 16:46:28 +0100
free_pages_nolock() and free_frozen_pages_nolock() put the page on
zone->trylock_free_pages if they get neither the pcp lock nor zone->lock.
add_page_to_zone_llist() keeps the order of the page in page->private.
The next free_one_page() which does get zone->lock passes these pages to
split_large_buddy() with ->private still set.
__free_one_page() writes ->private of the head of the resulting free page
only. If the deferred page is merged with its lower buddy, it becomes a
tail of that free page and keeps the order in ->private.
All other free pages which are not the head of a buddy have a ->private
of zero, and since commit 819bfbd47e49 ("mm/page_alloc: remove
set_page_private() in prep_compound_tail()") the allocator relies on it.
When the stale page is allocated again as a tail of a larger page:
- prep_compound_tail() hits VM_WARN_ON_ONCE(tail->private);
- with the page checks enabled, __free_pages_prepare() reports
"BUG: Bad page state", "nonzero private", and leaks the whole page;
- without them the value is seen by whoever uses that page next, e.g. as
folio->private of a folio which is split off a large folio.
Only pages of an order above zero are affected. Those can be freed
through _nolock() by the stack depot (order 2) and by SLUB (a new slab
which cannot be added to the partial list by kmalloc_nolock()).
Clear ->private when the page is taken off the list.
Link: https://lore.kernel.org/20261027-pgalloc-ai-hotfixes-v1-2-9c7d1aca801e@kernel.org
Fixes: 8c57b687e833 ("mm, bpf: Introduce free_pages_nolock()")
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Zi Yan <ziy@nvidia.com>
Assisted-by: LLM
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Brendan Jackman <brendan.jackman@linux.dev>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: "Gregory Price (Meta)" <gourry@gourry.net>
Cc: <stable@vger.kernel.org>
---
mm/page_alloc.c | 2 ++
1 file changed, 2 insertions(+)
--- a/mm/page_alloc.c~mm-page_alloc-clear-private-of-deferred-free-pages
+++ a/mm/page_alloc.c
@@ -1562,6 +1562,8 @@ static void free_one_page(struct zone *z
llist_for_each_entry_safe(p, tmp, llnode, pcp_llist) {
unsigned int p_order = p->private;
+ /* It may end up as a tail of the merged free page. */
+ p->private = 0;
split_large_buddy(zone, p, page_to_pfn(p), p_order, fpi_flags);
__count_vm_events(PGFREE, 1 << p_order);
}
_
Patches currently in -mm which might be from josef@toxicpanda.com are
mm-page_frag-refill-the-cache-for-large-fragments.patch
mm-page_alloc-keep-the-pagesets-of-an-empty-zone.patch
mm-page_alloc-pass-zone-pointer-to-trace_reclaim_retry_zone.patch
mm-compaction-trust-zone-contiguous-only-in-the-span.patch
mm-page_isolation-do-not-take-slab-pages-for-free.patch
mm-memory_hotplug-resize-zones-under-their-seqlock.patch
mm-page_alloc-check-pageblock-pfns-under-span-seqlock.patch
mm-filemap-dont-lose-a-folio-lock-wakeup-to-a-signal.patch
reply other threads:[~2026-10-28 3:06 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261028030638.9AA8B1F01828@smtp.kernel.org \
--to=akpm@linux-foundation.org \
--cc=josef@toxicpanda.com \
--cc=mm-commits@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.