* [PATCH] mm/vmalloc: Do not warn on -ENOMEM from va_alloc()
@ 2026-08-02 10:46 Uladzislau Rezki (Sony)
2026-08-03 3:49 ` Anshuman Khandual
2026-08-03 6:34 ` Baoquan He
0 siblings, 2 replies; 4+ messages in thread
From: Uladzislau Rezki (Sony) @ 2026-08-02 10:46 UTC (permalink / raw)
To: linux-mm, Andrew Morton
Cc: Baoquan He, LKML, Uladzislau Rezki, syzbot+61c997e6be1d9bb300ba
Since vmalloc() accepts non-blocking GFP flags, allocation
requests may fail when callers pass restrictive GFP masks.
va_clip() may return -ENOMEM when its GFP_NOWAIT fallback
allocation fails during NE_FIT_TYPE splitting. This is an
expected failure, so va_alloc() should return the error
without triggering a kernel splat.
Reported-by: syzbot+61c997e6be1d9bb300ba@syzkaller.appspotmail.com
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
---
mm/vmalloc.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 1afca3568b9b..7a0cbba3d29d 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1817,8 +1817,10 @@ va_alloc(struct vmap_area *va,
/* Update the free vmap_area. */
ret = va_clip(root, head, va, nva_start_addr, size);
- if (WARN_ON_ONCE(ret))
+ if (ret) {
+ WARN_ON_ONCE(ret != -ENOMEM);
return ret;
+ }
return nva_start_addr;
}
@@ -1891,12 +1893,9 @@ preload_this_cpu_lock(spinlock_t *lock, gfp_t gfp_mask, int node)
/*
* Preload this CPU with one extra vmap_area object. It is used
- * when fit type of free area is NE_FIT_TYPE. It guarantees that
- * a CPU that does an allocation is preloaded.
- *
- * We do it in non-atomic context, thus it allows us to use more
- * permissive allocation masks to be more stable under low memory
- * condition and high memory pressure.
+ * when fit type of free area is NE_FIT_TYPE. It is best effort
+ * pre-loading. If it fails va_clip() may return -ENOMEM from its
+ * GFP_NOWAIT fallback.
*/
if (!this_cpu_read(ne_fit_preload_node))
va = kmem_cache_alloc_node(vmap_area_cachep, gfp_mask, node);
--
2.47.3
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH] mm/vmalloc: Do not warn on -ENOMEM from va_alloc()
2026-08-02 10:46 [PATCH] mm/vmalloc: Do not warn on -ENOMEM from va_alloc() Uladzislau Rezki (Sony)
@ 2026-08-03 3:49 ` Anshuman Khandual
2026-08-03 13:40 ` Uladzislau Rezki
2026-08-03 6:34 ` Baoquan He
1 sibling, 1 reply; 4+ messages in thread
From: Anshuman Khandual @ 2026-08-03 3:49 UTC (permalink / raw)
To: Uladzislau Rezki (Sony)
Cc: linux-mm, Andrew Morton, Baoquan He, LKML,
syzbot+61c997e6be1d9bb300ba
On Sun, Aug 02, 2026 at 12:46:27PM +0200, Uladzislau Rezki (Sony) wrote:
> Since vmalloc() accepts non-blocking GFP flags, allocation
> requests may fail when callers pass restrictive GFP masks.
>
> va_clip() may return -ENOMEM when its GFP_NOWAIT fallback
> allocation fails during NE_FIT_TYPE splitting. This is an
> expected failure, so va_alloc() should return the error
> without triggering a kernel splat.
Dropping WARN_ON_ONCE() just for -ENOMEM while preserving this
warning for other returned errors does make sense.
>
> Reported-by: syzbot+61c997e6be1d9bb300ba@syzkaller.appspotmail.com
Very small nit.
If there is actual link for the problem report, probably it could
be added as an Link: or Closes: here.
> Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> mm/vmalloc.c | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 1afca3568b9b..7a0cbba3d29d 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -1817,8 +1817,10 @@ va_alloc(struct vmap_area *va,
>
> /* Update the free vmap_area. */
> ret = va_clip(root, head, va, nva_start_addr, size);
> - if (WARN_ON_ONCE(ret))
> + if (ret) {
> + WARN_ON_ONCE(ret != -ENOMEM);
> return ret;
> + }
>
> return nva_start_addr;
> }
> @@ -1891,12 +1893,9 @@ preload_this_cpu_lock(spinlock_t *lock, gfp_t gfp_mask, int node)
>
> /*
> * Preload this CPU with one extra vmap_area object. It is used
> - * when fit type of free area is NE_FIT_TYPE. It guarantees that
> - * a CPU that does an allocation is preloaded.
> - *
> - * We do it in non-atomic context, thus it allows us to use more
> - * permissive allocation masks to be more stable under low memory
> - * condition and high memory pressure.
> + * when fit type of free area is NE_FIT_TYPE. It is best effort
> + * pre-loading. If it fails va_clip() may return -ENOMEM from its
> + * GFP_NOWAIT fallback.
> */
> if (!this_cpu_read(ne_fit_preload_node))
> va = kmem_cache_alloc_node(vmap_area_cachep, gfp_mask, node);
> --
> 2.47.3
>
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] mm/vmalloc: Do not warn on -ENOMEM from va_alloc()
2026-08-03 3:49 ` Anshuman Khandual
@ 2026-08-03 13:40 ` Uladzislau Rezki
0 siblings, 0 replies; 4+ messages in thread
From: Uladzislau Rezki @ 2026-08-03 13:40 UTC (permalink / raw)
To: Anshuman Khandual
Cc: Uladzislau Rezki (Sony), linux-mm, Andrew Morton, Baoquan He,
LKML, syzbot+61c997e6be1d9bb300ba
On Mon, Aug 03, 2026 at 09:19:52AM +0530, Anshuman Khandual wrote:
> On Sun, Aug 02, 2026 at 12:46:27PM +0200, Uladzislau Rezki (Sony) wrote:
> > Since vmalloc() accepts non-blocking GFP flags, allocation
> > requests may fail when callers pass restrictive GFP masks.
> >
> > va_clip() may return -ENOMEM when its GFP_NOWAIT fallback
> > allocation fails during NE_FIT_TYPE splitting. This is an
> > expected failure, so va_alloc() should return the error
> > without triggering a kernel splat.
>
> Dropping WARN_ON_ONCE() just for -ENOMEM while preserving this
> warning for other returned errors does make sense.
>
> >
> > Reported-by: syzbot+61c997e6be1d9bb300ba@syzkaller.appspotmail.com
>
> Very small nit.
>
> If there is actual link for the problem report, probably it could
> be added as an Link: or Closes: here.
>
I hope Andrew can help here. If not i will resend!
Thank you!
--
Uladzislau Rezki
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] mm/vmalloc: Do not warn on -ENOMEM from va_alloc()
2026-08-02 10:46 [PATCH] mm/vmalloc: Do not warn on -ENOMEM from va_alloc() Uladzislau Rezki (Sony)
2026-08-03 3:49 ` Anshuman Khandual
@ 2026-08-03 6:34 ` Baoquan He
1 sibling, 0 replies; 4+ messages in thread
From: Baoquan He @ 2026-08-03 6:34 UTC (permalink / raw)
To: Uladzislau Rezki (Sony)
Cc: linux-mm, Andrew Morton, Baoquan He, LKML,
syzbot+61c997e6be1d9bb300ba
On 08/02/26 at 12:46pm, Uladzislau Rezki (Sony) wrote:
> Since vmalloc() accepts non-blocking GFP flags, allocation
> requests may fail when callers pass restrictive GFP masks.
>
> va_clip() may return -ENOMEM when its GFP_NOWAIT fallback
> allocation fails during NE_FIT_TYPE splitting. This is an
> expected failure, so va_alloc() should return the error
> without triggering a kernel splat.
>
> Reported-by: syzbot+61c997e6be1d9bb300ba@syzkaller.appspotmail.com
> Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
> ---
> mm/vmalloc.c | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 1afca3568b9b..7a0cbba3d29d 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -1817,8 +1817,10 @@ va_alloc(struct vmap_area *va,
>
> /* Update the free vmap_area. */
> ret = va_clip(root, head, va, nva_start_addr, size);
> - if (WARN_ON_ONCE(ret))
> + if (ret) {
> + WARN_ON_ONCE(ret != -ENOMEM);
> return ret;
> + }
>
> return nva_start_addr;
> }
> @@ -1891,12 +1893,9 @@ preload_this_cpu_lock(spinlock_t *lock, gfp_t gfp_mask, int node)
>
> /*
> * Preload this CPU with one extra vmap_area object. It is used
> - * when fit type of free area is NE_FIT_TYPE. It guarantees that
> - * a CPU that does an allocation is preloaded.
> - *
> - * We do it in non-atomic context, thus it allows us to use more
> - * permissive allocation masks to be more stable under low memory
> - * condition and high memory pressure.
> + * when fit type of free area is NE_FIT_TYPE. It is best effort
> + * pre-loading. If it fails va_clip() may return -ENOMEM from its
> + * GFP_NOWAIT fallback.
> */
> if (!this_cpu_read(ne_fit_preload_node))
> va = kmem_cache_alloc_node(vmap_area_cachep, gfp_mask, node);
LGTM,
Reviewed-by: Baoquan He <baoquan.he@linux.dev>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-08-03 13:40 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-02 10:46 [PATCH] mm/vmalloc: Do not warn on -ENOMEM from va_alloc() Uladzislau Rezki (Sony)
2026-08-03 3:49 ` Anshuman Khandual
2026-08-03 13:40 ` Uladzislau Rezki
2026-08-03 6:34 ` Baoquan He
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox