Re: [PATCH v4 1/3] vmalloc: add __GFP_SKIP_KASAN support

From: Catalin Marinas

Date: Wed Apr 29 2026 - 10:48:57 EST


On Wed, Apr 29, 2026 at 03:57:02PM +0530, Dev Jain wrote:
> From: Muhammad Usama Anjum <usama.anjum@xxxxxxx>
>
> For allocations that will be accessed only with match-all pointers
> (e.g., kernel stacks), setting tags is wasted work. If the caller
> already set __GFP_SKIP_KASAN, skip tag setting of vmalloc pages.
>
> Before this patch, __GFP_SKIP_KASAN wasn't being used with vmalloc
> APIs. So it wasn't being checked. Now its being checked and acted
> upon. Other KASAN modes are unchanged because __GFP_SKIP_KASAN is
> ignored for them in the page allocator, and in vmalloc too we ignore
> this flag for them.
>
> This is a preparatory patch for optimizing kernel stack allocations.
>
> Signed-off-by: Muhammad Usama Anjum <usama.anjum@xxxxxxx>
> Co-developed-by: Ryan Roberts <ryan.roberts@xxxxxxx>
> Signed-off-by: Ryan Roberts <ryan.roberts@xxxxxxx>
> Co-developed-by: Dev Jain <dev.jain@xxxxxxx>
> Signed-off-by: Dev Jain <dev.jain@xxxxxxx>
> ---
> include/linux/gfp_types.h | 6 +++---
> mm/vmalloc.c | 13 +++++++++----
> 2 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
> index 6c75df30a281d..c2bd723c8ec62 100644
> --- a/include/linux/gfp_types.h
> +++ b/include/linux/gfp_types.h
> @@ -281,9 +281,9 @@ enum {
> *
> * %__GFP_SKIP_KASAN makes KASAN skip unpoisoning on page allocation.
> * Used for userspace and vmalloc pages; the latter are unpoisoned by
> - * kasan_unpoison_vmalloc instead. For userspace pages, results in
> - * poisoning being skipped as well, see should_skip_kasan_poison for
> - * details. Only effective in HW_TAGS mode.
> + * kasan_unpoison_vmalloc instead. If passed to vmalloc, kasan_unpoison_vmalloc
> + * is skipped too. For userspace pages, results in poisoning being skipped as
> + * well, see should_skip_kasan_poison for details. Only effective in HW_TAGS mode.

Nit: keep the comment line length to less than 80, ideally close to the
comments above (for esthetic reasons).

Reviewed-by: Catalin Marinas <catalin.marinas@xxxxxxx>