From: Baoquan He <bhe@redhat.com>
To: Shivank Garg <shivankg@amd.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, urezki@gmail.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] mm/vmalloc.c: return explicit error value in alloc_vmap_area()
Date: Tue, 15 Apr 2025 21:01:51 +0800 [thread overview]
Message-ID: <Z/5Yv+iFmFPuFqvn@fedora> (raw)
In-Reply-To: <134bd404-d741-40ec-a661-f897da5ca9ca@amd.com>
On 04/15/25 at 12:52pm, Shivank Garg wrote:
> On 4/15/2025 8:09 AM, Baoquan He wrote:
> > In codes of alloc_vmap_area(), it returns the upper bound 'vend' to
> > indicate if the allocation is successful or failed. That is not very clear.
> >
> > Here change to return explicit error values and check them to judge if
> > allocation is successful.
> >
> > IS_ERR_VALUE already uses unlikely() internally
> >
> > Signed-off-by: Baoquan He <bhe@redhat.com>
> > ---
> > mm/vmalloc.c | 34 +++++++++++++++++-----------------
> > 1 file changed, 17 insertions(+), 17 deletions(-)
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index 3f38a232663b..5b21cd09b2b4 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -1715,7 +1715,7 @@ va_clip(struct rb_root *root, struct list_head *head,
> > */
> > lva = kmem_cache_alloc(vmap_area_cachep, GFP_NOWAIT);
> > if (!lva)
> > - return -1;
> > + return -ENOMEM;
> > }
> >
> > /*
> > @@ -1729,7 +1729,7 @@ va_clip(struct rb_root *root, struct list_head *head,
> > */
> > va->va_start = nva_start_addr + size;
> > } else {
> > - return -1;
> > + return -EINVAL;
> > }
Thanks for reviewing.
>
> Braces around return -EINVAL seem unnecessary.
> They can be dropped.
This complys with the codeing style required in 3) Placing Braces and
Spaces of Documentation/process/coding-style.rst because other branches
are multiple statements.
>
> >
> > if (type != FL_FIT_TYPE) {
> > @@ -1758,19 +1758,19 @@ va_alloc(struct vmap_area *va,
> >
> > /* Check the "vend" restriction. */
> > if (nva_start_addr + size > vend)
> > - return vend;
> > + return -ERANGE;
> >
> > /* Update the free vmap_area. */
> > ret = va_clip(root, head, va, nva_start_addr, size);
> > - if (WARN_ON_ONCE(ret))
> > - return vend;
> > + if (ret)
> > + return ret;
>
> Is it safe to remove the warning, or was it critical for debugging?
This comes from a reported concern because va_clip() could be failed by
NOTHING_FIT or kmem_cache_alloc failure. The warning here could cause
confusion misleading people to think vmap area management is failed.
>
> >
> > return nva_start_addr;
> > }
> >
> > /*
> > * Returns a start address of the newly allocated area, if success.
> > - * Otherwise a vend is returned that indicates failure.
> > + * Otherwise an error value is returned that indicates failure.
> > */
> > static __always_inline unsigned long
> > __alloc_vmap_area(struct rb_root *root, struct list_head *head,
> > @@ -1795,14 +1795,13 @@ __alloc_vmap_area(struct rb_root *root, struct list_head *head,
> >
> > va = find_vmap_lowest_match(root, size, align, vstart, adjust_search_size);
> > if (unlikely(!va))
> > - return vend;
> > + return -ENOENT;
> >
> > nva_start_addr = va_alloc(va, root, head, size, align, vstart, vend);
> > - if (nva_start_addr == vend)
> > - return vend;
> >
> > #if DEBUG_AUGMENT_LOWEST_MATCH_CHECK
> > - find_vmap_lowest_match_check(root, head, size, align);
> > + if (!IS_ERR_VALUE(nva_start_addr))
> > + find_vmap_lowest_match_check(root, head, size, align);
> > #endif
> >
> > return nva_start_addr;
> > @@ -1932,7 +1931,7 @@ node_alloc(unsigned long size, unsigned long align,
> > struct vmap_area *va;
> >
> > *vn_id = 0;
> > - *addr = vend;
> > + *addr = -EINVAL;
> >
> > /*
> > * Fallback to a global heap if not vmalloc or there
> > @@ -2012,20 +2011,20 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
> > }
> >
> > retry:
> > - if (addr == vend) {
> > + if (IS_ERR_VALUE(addr)) {
> > preload_this_cpu_lock(&free_vmap_area_lock, gfp_mask, node);
> > addr = __alloc_vmap_area(&free_vmap_area_root, &free_vmap_area_list,
> > size, align, vstart, vend);
> > spin_unlock(&free_vmap_area_lock);
> > }
> >
> > - trace_alloc_vmap_area(addr, size, align, vstart, vend, addr == vend);
> > + trace_alloc_vmap_area(addr, size, align, vstart, vend, IS_ERR_VALUE(addr));
> >
> > /*
> > - * If an allocation fails, the "vend" address is
> > + * If an allocation fails, the error value is
> > * returned. Therefore trigger the overflow path.
> > */
> > - if (unlikely(addr == vend))
> > + if (IS_ERR_VALUE(addr))
> > goto overflow;
> >
> > va->va_start = addr;
> > @@ -4753,9 +4752,10 @@ 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))) {
> ^^ ^^
> The extra parentheses are redundant and can be removed for clarity.
You are right, I will remove it. Thanks.
>
> > + WARN_ONCE(1, "%s error: errno (%d)\n", __func__, ret);
> > goto recovery;
> > + }
> >
> > /* Allocated area. */
> > va = vas[area];
>
next prev parent reply other threads:[~2025-04-15 13:02 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-15 2:39 [PATCH 0/5] mm/vmalloc.c: code cleanup and improvements Baoquan He
2025-04-15 2:39 ` [PATCH 1/5] mm/vmalloc.c: change purge_ndoes as local static variable Baoquan He
2025-04-15 10:47 ` Uladzislau Rezki
2025-04-15 19:08 ` Shivank Garg
2025-04-15 23:53 ` Vishal Moola (Oracle)
2025-04-15 2:39 ` [PATCH 2/5] mm/vmalloc.c: find the vmap of vmap_nodes in reverse order Baoquan He
2025-04-15 15:25 ` Uladzislau Rezki
2025-04-15 23:41 ` Baoquan He
2025-04-15 19:09 ` Shivank Garg
2025-04-15 2:39 ` [PATCH 3/5] mm/vmalloc.c: optimize code in decay_va_pool_node() a little bit Baoquan He
2025-04-15 10:29 ` Shivank Garg
2025-04-15 14:05 ` Baoquan He
2025-04-15 19:02 ` Shivank Garg
2025-04-16 13:50 ` Uladzislau Rezki
2025-04-17 2:51 ` Baoquan He
2025-04-17 16:18 ` Uladzislau Rezki
2025-04-15 2:39 ` [PATCH 4/5] mm/vmalloc: optimize function vm_unmap_aliases() Baoquan He
2025-04-15 10:44 ` Uladzislau Rezki
2025-04-15 19:10 ` Shivank Garg
2025-04-15 23:54 ` Vishal Moola (Oracle)
2025-04-15 2:39 ` [PATCH 5/5] mm/vmalloc.c: return explicit error value in alloc_vmap_area() Baoquan He
2025-04-15 6:44 ` Baoquan He
2025-04-15 7:22 ` Shivank Garg
2025-04-15 13:01 ` Baoquan He [this message]
2025-04-15 19:00 ` Shivank Garg
2025-04-15 22:57 ` Baoquan He
2025-04-16 14:28 ` Uladzislau Rezki
2025-04-17 3:02 ` Baoquan He
2025-04-17 16:17 ` Uladzislau Rezki
2025-04-15 15:29 ` [PATCH 0/5] mm/vmalloc.c: code cleanup and improvements Uladzislau Rezki
2025-04-15 22:55 ` Baoquan He
2025-04-15 19:06 ` Shivank Garg
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=Z/5Yv+iFmFPuFqvn@fedora \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shivankg@amd.com \
--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.