From: Uladzislau Rezki <urezki@gmail.com>
To: Michal Hocko <mhocko@suse.com>
Cc: "Uladzislau Rezki (Sony)" <urezki@gmail.com>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>, Baoquan He <bhe@redhat.com>
Subject: Re: [RFC 6/7] mm/vmalloc: Support non-blocking GFP flags in __vmalloc_area_node()
Date: Wed, 9 Jul 2025 15:45:19 +0200 [thread overview]
Message-ID: <aG5ybxhmNDR4_kCy@pc636> (raw)
In-Reply-To: <aG09iVrHBPYPkp-Y@tiehlicka>
On Tue, Jul 08, 2025 at 05:47:21PM +0200, Michal Hocko wrote:
> On Fri 04-07-25 17:25:36, Uladzislau Rezki wrote:
> > This patch makes __vmalloc_area_node() to correctly handle non-blocking
> > allocation requests, such as GFP_ATOMIC and GFP_NOWAIT. Main changes:
> >
> > - nested_gfp flag follows the same non-blocking constraints
> > as the primary gfp_mask, ensuring consistency and avoiding
> > sleeping allocations in atomic contexts.
> >
> > - if blocking is not allowed, __GFP_NOFAIL is forcibly cleared
> > and warning is issued if it was set, since __GFP_NOFAIL is
> > incompatible with non-blocking contexts;
> >
> > - Add a __GFP_HIGHMEM to gfp_mask only for blocking requests
> > if there are no DMA constraints.
> >
> > - in non-blocking mode we use memalloc_noreclaim_save/restore()
> > to prevent reclaim related operations that may sleep while
> > setting up page tables or mapping pages.
> >
> > This is particularly important for page table allocations that
> > internally use GFP_PGTABLE_KERNEL, which may sleep unless such
> > scope restrictions are applied. For example:
> >
> > <snip>
> > #define GFP_PGTABLE_KERNEL (GFP_KERNEL | __GFP_ZERO)
> >
> > __pte_alloc_kernel()
> > pte_alloc_one_kernel(&init_mm);
> > pagetable_alloc_noprof(GFP_PGTABLE_KERNEL & ~__GFP_HIGHMEM, 0);
> > <snip>
> >
> > Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
> > ---
> > mm/vmalloc.c | 30 +++++++++++++++++++++++++-----
> > 1 file changed, 25 insertions(+), 5 deletions(-)
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index 2eaff0575a9e..fe1699e01e02 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -3711,7 +3711,7 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> > pgprot_t prot, unsigned int page_shift,
> > int node)
> > {
> > - const gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
> > + gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
> > bool nofail = gfp_mask & __GFP_NOFAIL;
> > unsigned long addr = (unsigned long)area->addr;
> > unsigned long size = get_vm_area_size(area);
> > @@ -3719,12 +3719,28 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> > unsigned int nr_small_pages = size >> PAGE_SHIFT;
> > unsigned int page_order;
> > unsigned int flags;
> > + bool noblock;
> > int ret;
> >
> > array_size = (unsigned long)nr_small_pages * sizeof(struct page *);
> > + noblock = !gfpflags_allow_blocking(gfp_mask);
> >
> > - if (!(gfp_mask & (GFP_DMA | GFP_DMA32)))
> > - gfp_mask |= __GFP_HIGHMEM;
> > + if (noblock) {
> > + /* __GFP_NOFAIL is incompatible with non-blocking contexts. */
> > + WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL);
> > + gfp_mask &= ~__GFP_NOFAIL;
>
> Btw. we already ignore GFP_NOFAIL for atomic allocations and warn about
> that at the page allocator level (__alloc_pages_slowpath)
>
Thank you. I will comment this!
>
> What we can do though is to add a pr_warn + dump_stack for request with
> size that would require (in the worst case) page tables allocation
> larger than a portion of min_free_kbytes (to scale with different memory
> sizes). That should be plenty for any reasonable non blocking vmalloc.
> We would have means to catch abusers in that way.
>
OK, i will add it. I assume you mean:
unsigned long pages_min = min_free_kbytes >> (PAGE_SHIFT - 10);
if (request_pages > pages_min)
dump();
--
Uladzislau Rezki
next prev parent reply other threads:[~2025-07-09 13:45 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-04 15:25 [RFC 0/7] vmallloc and non-blocking GFPs Uladzislau Rezki (Sony)
2025-07-04 15:25 ` [RFC 1/7] lib/test_vmalloc: Add non-block-alloc-test case Uladzislau Rezki (Sony)
2025-07-08 5:59 ` [External] " Adrian Huang12
2025-07-08 8:29 ` Uladzislau Rezki
2025-07-04 15:25 ` [RFC 2/7] mm/vmalloc: Support non-blocking GFP flags in alloc_vmap_area() Uladzislau Rezki (Sony)
2025-07-07 7:11 ` Michal Hocko
2025-07-08 12:34 ` Uladzislau Rezki
2025-07-08 15:17 ` Michal Hocko
2025-07-08 16:45 ` Uladzislau Rezki
2025-07-04 15:25 ` [RFC 3/7] mm/vmalloc: Avoid cond_resched() when blocking is not permitted Uladzislau Rezki (Sony)
2025-07-07 7:11 ` Michal Hocko
2025-07-08 12:29 ` Uladzislau Rezki
2025-07-04 15:25 ` [RFC 4/7] mm/kasan, mm/vmalloc: Respect GFP flags in kasan_populate_vmalloc() Uladzislau Rezki (Sony)
2025-07-07 1:47 ` Baoquan He
2025-07-08 1:15 ` Baoquan He
2025-07-08 8:30 ` Uladzislau Rezki
2025-07-04 15:25 ` [RFC 5/7] mm/vmalloc: Defer freeing partly initialized vm_struct Uladzislau Rezki (Sony)
2025-07-04 15:25 ` [RFC 6/7] mm/vmalloc: Support non-blocking GFP flags in __vmalloc_area_node() Uladzislau Rezki (Sony)
2025-07-07 7:13 ` Michal Hocko
2025-07-08 12:27 ` Uladzislau Rezki
2025-07-08 15:22 ` Michal Hocko
2025-07-09 11:20 ` Uladzislau Rezki
2025-07-08 15:47 ` Michal Hocko
2025-07-09 13:45 ` Uladzislau Rezki [this message]
2025-07-04 15:25 ` [RFC 7/7] mm: Drop __GFP_DIRECT_RECLAIM flag if PF_MEMALLOC is set Uladzislau Rezki (Sony)
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=aG5ybxhmNDR4_kCy@pc636 \
--to=urezki@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.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.