From: Baoquan He <bhe@redhat.com>
To: "Uladzislau Rezki (Sony)" <urezki@gmail.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 10/10] mm: kvmalloc: Add non-blocking support for vmalloc
Date: Sat, 4 Oct 2025 12:37:07 +0800 [thread overview]
Message-ID: <aOCkc27YVRVa8PBW@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20251001192647.195204-11-urezki@gmail.com>
On 10/01/25 at 09:26pm, Uladzislau Rezki (Sony) wrote:
> Extend __kvmalloc_node_noprof() to handle non-blocking GFP flags
> (GFP_NOWAIT and GFP_ATOMIC). Previously such flags were rejected,
> returning NULL. With this change:
>
> - kvmalloc() can fall back to vmalloc() if non-blocking contexts;
> - for non-blocking allocations the VM_ALLOW_HUGE_VMAP option is
> disabled, since the huge mapping path still contains might_sleep();
> - documentation update to reflect that GFP_NOWAIT and GFP_ATOMIC
> are now supported.
>
> Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
> ---
> mm/slub.c | 19 +++++++++++++------
> 1 file changed, 13 insertions(+), 6 deletions(-)
Reviewed-by: Baoquan He <bhe@redhat.com>
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 584a5ff1828b..3de0719e24e9 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -7018,7 +7018,7 @@ static gfp_t kmalloc_gfp_adjust(gfp_t flags, size_t size)
> * Uses kmalloc to get the memory but if the allocation fails then falls back
> * to the vmalloc allocator. Use kvfree for freeing the memory.
> *
> - * GFP_NOWAIT and GFP_ATOMIC are not supported, neither is the __GFP_NORETRY modifier.
> + * GFP_NOWAIT and GFP_ATOMIC are supported, the __GFP_NORETRY modifier is not.
> * __GFP_RETRY_MAYFAIL is supported, and it should be used only if kmalloc is
> * preferable to the vmalloc fallback, due to visible performance drawbacks.
> *
> @@ -7027,6 +7027,7 @@ static gfp_t kmalloc_gfp_adjust(gfp_t flags, size_t size)
> void *__kvmalloc_node_noprof(DECL_BUCKET_PARAMS(size, b), unsigned long align,
> gfp_t flags, int node)
> {
> + bool allow_block;
> void *ret;
>
> /*
> @@ -7039,16 +7040,22 @@ void *__kvmalloc_node_noprof(DECL_BUCKET_PARAMS(size, b), unsigned long align,
> if (ret || size <= PAGE_SIZE)
> return ret;
>
> - /* non-sleeping allocations are not supported by vmalloc */
> - if (!gfpflags_allow_blocking(flags))
> - return NULL;
> -
> /* Don't even allow crazy sizes */
> if (unlikely(size > INT_MAX)) {
> WARN_ON_ONCE(!(flags & __GFP_NOWARN));
> return NULL;
> }
>
> + /*
> + * For non-blocking the VM_ALLOW_HUGE_VMAP is not used
> + * because the huge-mapping path in vmalloc contains at
> + * least one might_sleep() call.
> + *
> + * TODO: Revise huge-mapping path to support non-blocking
> + * flags.
> + */
> + allow_block = gfpflags_allow_blocking(flags);
> +
> /*
> * kvmalloc() can always use VM_ALLOW_HUGE_VMAP,
> * since the callers already cannot assume anything
> @@ -7056,7 +7063,7 @@ void *__kvmalloc_node_noprof(DECL_BUCKET_PARAMS(size, b), unsigned long align,
> * protection games.
> */
> return __vmalloc_node_range_noprof(size, align, VMALLOC_START, VMALLOC_END,
> - flags, PAGE_KERNEL, VM_ALLOW_HUGE_VMAP,
> + flags, PAGE_KERNEL, allow_block ? VM_ALLOW_HUGE_VMAP:0,
> node, __builtin_return_address(0));
> }
> EXPORT_SYMBOL(__kvmalloc_node_noprof);
> --
> 2.47.3
>
prev parent reply other threads:[~2025-10-04 4:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-01 19:26 [PATCH v3 00/10] __vmalloc()/kvmalloc() and no-block support(v3) Uladzislau Rezki (Sony)
2025-10-01 19:26 ` [PATCH v3 01/10] lib/test_vmalloc: add no_block_alloc_test case Uladzislau Rezki (Sony)
2025-10-01 19:26 ` [PATCH v3 02/10] lib/test_vmalloc: Remove xfail condition check Uladzislau Rezki (Sony)
2025-10-01 19:26 ` [PATCH v3 03/10] mm/vmalloc: Support non-blocking GFP flags in alloc_vmap_area() Uladzislau Rezki (Sony)
2025-10-01 19:26 ` [PATCH v3 04/10] mm/vmalloc: Defer freeing partly initialized vm_struct Uladzislau Rezki (Sony)
2025-10-01 19:26 ` [PATCH v3 05/10] mm/vmalloc: Handle non-blocking GFP in __vmalloc_area_node() Uladzislau Rezki (Sony)
2025-10-01 19:26 ` [PATCH v3 06/10] mm/kasan: Support non-blocking GFP in kasan_populate_vmalloc() Uladzislau Rezki (Sony)
2025-10-01 19:26 ` [PATCH v3 07/10] kmsan: Remove hard-coded GFP_KERNEL flags Uladzislau Rezki (Sony)
2025-10-01 19:26 ` [PATCH v3 08/10] mm: Skip might_alloc() warnings when PF_MEMALLOC is set Uladzislau Rezki (Sony)
2025-10-04 3:53 ` Baoquan He
2025-10-01 19:26 ` [PATCH v3 09/10] mm/vmalloc: Update __vmalloc_node_range() documentation Uladzislau Rezki (Sony)
2025-10-04 4:11 ` Baoquan He
2025-10-04 5:02 ` Baoquan He
2025-10-06 10:06 ` Uladzislau Rezki
2025-10-06 13:17 ` Baoquan He
2025-10-07 9:42 ` Uladzislau Rezki
2025-10-07 9:53 ` Baoquan He
2025-10-01 19:26 ` [PATCH v3 10/10] mm: kvmalloc: Add non-blocking support for vmalloc Uladzislau Rezki (Sony)
2025-10-03 6:30 ` Michal Hocko
2025-10-04 4:37 ` Baoquan He [this message]
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=aOCkc27YVRVa8PBW@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=urezki@gmail.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.