All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 [PATCH] mm/vmalloc: do not warn on -ENOMEM from va_clip() in pcpu_get_vm_areas() 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 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.