linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: linux-mm@kvack.org
Cc: akpm@linux-foundation.org, urezki@gmail.com,
	linux-kernel@vger.kernel.org, Baoquan He <bhe@redhat.com>
Subject: [PATCH 5/5] mm/vmalloc.c: return explicit error value in alloc_vmap_area()
Date: Tue, 15 Apr 2025 10:39:52 +0800	[thread overview]
Message-ID: <20250415023952.27850-6-bhe@redhat.com> (raw)
In-Reply-To: <20250415023952.27850-1-bhe@redhat.com>

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;
 	}
 
 	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;
 
 	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))) {
+			WARN_ONCE(1, "%s error: errno (%d)\n", __func__, ret);
 			goto recovery;
+		}
 
 		/* Allocated area. */
 		va = vas[area];
-- 
2.41.0



  parent reply	other threads:[~2025-04-15  2:40 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 ` Baoquan He [this message]
2025-04-15  6:44   ` [PATCH 5/5] mm/vmalloc.c: return explicit error value in alloc_vmap_area() Baoquan He
2025-04-15  7:22   ` Shivank Garg
2025-04-15 13:01     ` Baoquan He
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=20250415023952.27850-6-bhe@redhat.com \
    --to=bhe@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).