From: Brendan Jackman <jackmanb@google.com>
To: Brendan Jackman <jackmanb@google.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Vlastimil Babka <vbabka@kernel.org>, Wei Xu <weixugc@google.com>,
Johannes Weiner <hannes@cmpxchg.org>, Zi Yan <ziy@nvidia.com>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
<x86@kernel.org>, <rppt@kernel.org>,
Sumit Garg <sumit.garg@oss.qualcomm.com>, <derkling@google.com>,
<reijiw@google.com>, Will Deacon <will@kernel.org>,
<rientjes@google.com>,
"Kalyazin, Nikita" <kalyazin@amazon.co.uk>,
<patrick.roy@linux.dev>,
"Itazuri, Takahiro" <itazur@amazon.co.uk>,
Andy Lutomirski <luto@kernel.org>,
David Kaplan <david.kaplan@amd.com>,
Thomas Gleixner <tglx@kernel.org>,
Yosry Ahmed <yosry.ahmed@linux.dev>
Subject: Re: [PATCH RFC 17/19] mm/page_alloc: implement __GFP_UNMAPPED allocations
Date: Fri, 27 Feb 2026 10:56:35 +0000 [thread overview]
Message-ID: <DGPOUOPLOPVK.29E3EI454OQ74@google.com> (raw)
In-Reply-To: <20260225-page_alloc-unmapped-v1-17-e8808a03cd66@google.com>
More bugs found by AI...
(I am not relaying all of the issues, just the interesting ones/ones in
the most interesting bits of code).
On Wed Feb 25, 2026 at 4:34 PM UTC, Brendan Jackman wrote:
> +/* Try to allocate a page by mapping/unmapping a block from the direct map. */
> +static inline struct page *
> +__rmqueue_direct_map(struct zone *zone, unsigned int request_order,
> + unsigned int alloc_flags, freetype_t freetype)
> +{
> + unsigned int ft_flags_other = freetype_flags(freetype) ^ FREETYPE_UNMAPPED;
> + freetype_t ft_other = migrate_to_freetype(free_to_migratetype(freetype),
> + ft_flags_other);
> + bool want_mapped = !(freetype_flags(freetype) & FREETYPE_UNMAPPED);
> + enum rmqueue_mode rmqm = RMQUEUE_NORMAL;
> + unsigned long irq_flags;
> + int nr_pageblocks;
> + struct page *page;
> + int alloc_order;
> + int err;
> +
> + if (freetype_idx(ft_other) < 0)
> + return NULL;
> +
> + /*
> + * Might need a TLB shootdown. Even if IRQs are on this isn't
> + * safe if the caller holds a lock (in case the other CPUs need that
> + * lock to handle the shootdown IPI).
> + */
> + if (alloc_flags & ALLOC_NOBLOCK)
> + return NULL;
> +
> + if (!can_set_direct_map())
> + return NULL;
> +
> + lockdep_assert(!irqs_disabled() || unlikely(early_boot_irqs_disabled));
> +
> + /*
> + * Need to [un]map a whole pageblock (otherwise it might require
> + * allocating pagetables). First allocate it.
> + */
> + alloc_order = max(request_order, pageblock_order);
> + nr_pageblocks = 1 << (alloc_order - pageblock_order);
> + spin_lock_irqsave(&zone->lock, irq_flags);
> + page = __rmqueue(zone, alloc_order, ft_other, alloc_flags, &rmqm);
> + spin_unlock_irqrestore(&zone->lock, irq_flags);
> + if (!page)
> + return NULL;
> +
> + /*
> + * Now that IRQs are on it's safe to do a TLB shootdown, and now that we
> + * released the zone lock it's possible to allocate a pagetable if
> + * needed to split up a huge page.
> + *
> + * Note that modifying the direct map may need to allocate pagetables.
> + * What about unbounded recursion? Here are the assumptions that make it
> + * safe:
> + *
> + * - The direct map starts out fully mapped at boot. (This is not really
> + * an assumption" as its in direct control of page_alloc.c).
> + *
> + * - Once pages in the direct map are broken down, they are not
> + * re-aggregated into larger pages again.
> + *
> + * - Pagetables are never allocated with __GFP_UNMAPPED.
> + *
> + * Under these assumptions, a pagetable might need to be allocated while
> + * _unmapping_ stuff from the direct map during a __GFP_UNMAPPED
> + * allocation. But, the allocation of that pagetable never requires
> + * allocating a further pagetable.
> + */
> + err = set_direct_map_valid_noflush(page,
> + nr_pageblocks << pageblock_order, want_mapped);
> + if (err == -ENOMEM || WARN_ONCE(err, "err=%d\n", err)) {
> + __free_one_page(page, page_to_pfn(page), zone,
> + alloc_order, freetype, FPI_SKIP_REPORT_NOTIFY);
Forgot to take the zone lock.
> + return NULL;
> + }
> +
> + if (!want_mapped) {
> + unsigned long start = (unsigned long)page_address(page);
> + unsigned long end = start + (nr_pageblocks << (pageblock_order + PAGE_SHIFT));
> +
> + flush_tlb_kernel_range(start, end);
> + }
> +
> + for (int i = 0; i < nr_pageblocks; i++) {
> + struct page *block_page = page + (pageblock_nr_pages * i);
> +
> + set_pageblock_freetype_flags(block_page, freetype_flags(freetype));
> + }
> +
> + if (request_order >= alloc_order)
> + return page;
> +
> + /* Free any remaining pages in the block. */
> + spin_lock_irqsave(&zone->lock, irq_flags);
> + for (unsigned int i = request_order; i < alloc_order; i++) {
> + struct page *page_to_free = page + (1 << i);
> +
> + __free_one_page(page_to_free, page_to_pfn(page_to_free), zone,
> + i, freetype, FPI_SKIP_REPORT_NOTIFY);
> + }
> + spin_unlock_irqrestore(&zone->lock, irq_flags);
> +
> + return page;
> +}
next prev parent reply other threads:[~2026-02-27 10:56 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-25 16:34 [PATCH RFC 00/19] mm: Add __GFP_UNMAPPED Brendan Jackman
2026-02-25 16:34 ` [PATCH RFC 01/19] x86/mm: split out preallocate_sub_pgd() Brendan Jackman
2026-02-25 16:34 ` [PATCH RFC 02/19] x86/mm: Generalize LDT remap into "mm-local region" Brendan Jackman
2026-02-25 16:34 ` [PATCH RFC 03/19] x86/tlb: Expose some flush function declarations to modules Brendan Jackman
2026-02-25 16:34 ` [PATCH RFC 04/19] x86/mm: introduce the mermap Brendan Jackman
2026-02-27 10:47 ` Brendan Jackman
2026-02-25 16:34 ` [PATCH RFC 05/19] mm: KUnit tests for " Brendan Jackman
2026-02-25 16:34 ` [PATCH RFC 06/19] mm: introduce for_each_free_list() Brendan Jackman
2026-02-25 16:34 ` [PATCH RFC 07/19] mm/page_alloc: don't overload migratetype in find_suitable_fallback() Brendan Jackman
2026-02-25 16:34 ` [PATCH RFC 08/19] mm: introduce freetype_t Brendan Jackman
2026-02-25 16:34 ` [PATCH RFC 09/19] mm: move migratetype definitions to freetype.h Brendan Jackman
2026-02-25 16:34 ` [PATCH RFC 10/19] mm: add definitions for allocating unmapped pages Brendan Jackman
2026-02-25 16:34 ` [PATCH RFC 11/19] mm: rejig pageblock mask definitions Brendan Jackman
2026-02-25 16:34 ` [PATCH RFC 12/19] mm: encode freetype flags in pageblock flags Brendan Jackman
2026-02-25 16:34 ` [PATCH RFC 13/19] mm/page_alloc: remove ifdefs from pindex helpers Brendan Jackman
2026-02-25 16:34 ` [PATCH RFC 14/19] mm/page_alloc: separate pcplists by freetype flags Brendan Jackman
2026-02-25 16:34 ` [PATCH RFC 15/19] mm/page_alloc: rename ALLOC_NON_BLOCK back to _HARDER Brendan Jackman
2026-02-25 16:34 ` [PATCH RFC 16/19] mm/page_alloc: introduce ALLOC_NOBLOCK Brendan Jackman
2026-02-25 16:34 ` [PATCH RFC 17/19] mm/page_alloc: implement __GFP_UNMAPPED allocations Brendan Jackman
2026-02-27 10:56 ` Brendan Jackman [this message]
2026-02-25 16:34 ` [PATCH RFC 18/19] mm/page_alloc: implement __GFP_UNMAPPED|__GFP_ZERO allocations Brendan Jackman
2026-02-27 11:04 ` Brendan Jackman
2026-02-25 16:34 ` [PATCH RFC 19/19] mm: Minimal KUnit tests for some new page_alloc logic Brendan Jackman
2026-03-02 15:36 ` [PATCH RFC 00/19] mm: Add __GFP_UNMAPPED Vlastimil Babka (SUSE)
2026-03-05 11:16 ` Brendan Jackman
2026-03-06 14:41 ` Borislav Petkov
2026-03-05 14:51 ` Kevin Brodsky
2026-03-05 15:58 ` Brendan Jackman
2026-03-06 12:31 ` Kevin Brodsky
2026-03-06 18:17 ` Mike Rapoport
2026-03-06 17:38 ` Edgecombe, Rick P
2026-03-16 16:01 ` Brendan Jackman
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=DGPOUOPLOPVK.29E3EI454OQ74@google.com \
--to=jackmanb@google.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david.kaplan@amd.com \
--cc=david@kernel.org \
--cc=derkling@google.com \
--cc=hannes@cmpxchg.org \
--cc=itazur@amazon.co.uk \
--cc=kalyazin@amazon.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=luto@kernel.org \
--cc=patrick.roy@linux.dev \
--cc=peterz@infradead.org \
--cc=reijiw@google.com \
--cc=rientjes@google.com \
--cc=rppt@kernel.org \
--cc=sumit.garg@oss.qualcomm.com \
--cc=tglx@kernel.org \
--cc=vbabka@kernel.org \
--cc=weixugc@google.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=yosry.ahmed@linux.dev \
--cc=ziy@nvidia.com \
/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.