From: Uladzislau Rezki <urezki@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Palla Raghunath <raghunathpalla.0209@gmail.com>,
linux-kernel@vger.kernel.org, Shuah Khan <shuah@kernel.org>,
Brigham Campbell <me@brighamcampbell.com>,
linux-kernel-mentees@lists.linux.dev,
syzbot+442828bb356b10813a47@syzkaller.appspotmail.com,
Uladzislau Rezki <urezki@gmail.com>,
Baoquan He <baoquan.he@linux.dev>,
linux-mm@kvack.org
Subject: Re: [PATCH] mm/vmalloc: do not warn on -ENOMEM from va_clip() in pcpu_get_vm_areas()
Date: Sat, 26 Sep 2026 11:05:45 +0200 [thread overview]
Message-ID: <areK6Z34m3gP7qe5@milan> (raw)
In-Reply-To: <20260925151500.75fcb001ef8cd7f4842e62aa@linux-foundation.org>
On Fri, Sep 25, 2026 at 03:15:00PM -0700, Andrew Morton wrote:
> On Fri, 25 Sep 2026 21:54:49 +0100 Palla Raghunath <raghunathpalla.0209@gmail.com> wrote:
>
> > When pcpu_get_vm_areas() has to split a free vmap_area in the middle
> > (NE_FIT_TYPE), va_clip() needs an extra vmap_area object. It takes the
> > per-cpu ne_fit_preload_node if one is there, and otherwise falls back
> > to kmem_cache_alloc(GFP_NOWAIT), which may fail and return -ENOMEM.
> > pcpu_get_vm_areas() never preloads, and a single call can do more than
> > one such split: on a NUMA system it places one area per node group, so
> > the first split consumes the preloaded object and the next one depends
> > on the GFP_NOWAIT allocation.
> >
> > That failure is expected and already handled: the recovery path returns
> > the areas clipped so far to the free tree, purges lazily freed areas and
> > retries. But the error is checked with WARN_ON_ONCE(), so a transient
> > allocation failure under memory pressure or fault injection triggers a
> > kernel warning, and a panic with panic_on_warn. syzbot hit this on a
> > two-node VM while creating a per-cpu BPF array map.
> >
> > Keep the WARN_ON_ONCE() for errors other than -ENOMEM, which do indicate
> > a bug, and take the recovery path either way. This matches what commit
> > b9183788a2de ("mm/vmalloc: do not warn on -ENOMEM from va_alloc()") did
> > for the other va_clip() caller.
> >
> > Fixes: 1b23ff80b399 ("mm/vmalloc: invoke classify_va_fit_type() in adjust_va_to_fit_type()")
> > Reported-by: syzbot+442828bb356b10813a47@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=442828bb356b10813a47
>
> I assume sysbot hit this via fault injection. The report doesn't make this
> info easily available. Or maybe it wasn't fault injection.
>
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -5107,9 +5107,14 @@ struct vm_struct **pcpu_get_vm_areas(const unsigned long *offsets,
> >
> > ret = va_clip(&free_vmap_area_root,
> > &free_vmap_area_list, va, start, size);
> > - if (WARN_ON_ONCE(unlikely(ret)))
> > - /* It is a BUG(), but trigger recovery instead. */
> > + if (unlikely(ret)) {
> > + /*
> > + * -ENOMEM from the GFP_NOWAIT fallback is expected.
> > + * Anything else is a BUG(), but trigger recovery instead.
> > + */
> > + WARN_ON_ONCE(ret != -ENOMEM);
>
> Look good.
>
> The WARN_ON_ONCE() is potentially redundant. We could make va_clip()
> remove __GFP_NOWARN from its kmem_cache_alloc() and let the page
> allocator do the warn for us. Doesn't matter.
>
The patch looks good to me also:
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
--
Uladzislau Rezki
next prev parent reply other threads:[~2026-09-26 9:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-25 20:54 Palla Raghunath
2026-09-25 22:15 ` Andrew Morton
2026-09-26 9:05 ` Uladzislau Rezki [this message]
2026-09-26 10:44 ` Dev Jain
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=areK6Z34m3gP7qe5@milan \
--to=urezki@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=baoquan.he@linux.dev \
--cc=linux-kernel-mentees@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=me@brighamcampbell.com \
--cc=raghunathpalla.0209@gmail.com \
--cc=shuah@kernel.org \
--cc=syzbot+442828bb356b10813a47@syzkaller.appspotmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®