From: Barry Song <21cnbao@gmail.com>
To: akpm@linux-foundation.org, linux-mm@kvack.org
Cc: Barry Song <v-songbaohua@oppo.com>,
Michal Hocko <mhocko@suse.com>,
Uladzislau Rezki <urezki@gmail.com>,
Christoph Hellwig <hch@infradead.org>,
Lorenzo Stoakes <lstoakes@gmail.com>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Vlastimil Babka <vbabka@suse.cz>,
Roman Gushchin <roman.gushchin@linux.dev>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>
Subject: [PATCH RFC] mm: warn potential return NULL for kmalloc_array and kvmalloc_array with __GFP_NOFAIL
Date: Thu, 18 Jul 2024 11:00:25 +1200 [thread overview]
Message-ID: <20240717230025.77361-1-21cnbao@gmail.com> (raw)
From: Barry Song <v-songbaohua@oppo.com>
Overflow in this context is highly unlikely. However, allocations using
GFP_NOFAIL are guaranteed to succeed, so checking the return value is
unnecessary. One option to fix this is allowing memory allocation with
an overflowed size, but it seems pointless. Let's at least issue a
warning. Likely BUG_ON() seems better as anyway we can't fix it?
Cc: Michal Hocko <mhocko@suse.com>
Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Signed-off-by: Barry Song <v-songbaohua@oppo.com>
---
include/linux/slab.h | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/linux/slab.h b/include/linux/slab.h
index a332dd2fa6cd..c6aec311864f 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -692,8 +692,10 @@ static inline __alloc_size(1, 2) void *kmalloc_array_noprof(size_t n, size_t siz
{
size_t bytes;
- if (unlikely(check_mul_overflow(n, size, &bytes)))
+ if (unlikely(check_mul_overflow(n, size, &bytes))) {
+ WARN_ON(flags & __GFP_NOFAIL);
return NULL;
+ }
if (__builtin_constant_p(n) && __builtin_constant_p(size))
return kmalloc_noprof(bytes, flags);
return kmalloc_noprof(bytes, flags);
@@ -794,8 +796,10 @@ kvmalloc_array_node_noprof(size_t n, size_t size, gfp_t flags, int node)
{
size_t bytes;
- if (unlikely(check_mul_overflow(n, size, &bytes)))
+ if (unlikely(check_mul_overflow(n, size, &bytes))) {
+ WARN_ON(flags & __GFP_NOFAIL);
return NULL;
+ }
return kvmalloc_node_noprof(bytes, flags, node);
}
--
2.34.1
next reply other threads:[~2024-07-17 23:00 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-17 23:00 Barry Song [this message]
2024-07-18 6:58 ` Michal Hocko
2024-07-18 7:04 ` Christoph Hellwig
2024-07-18 7:12 ` Michal Hocko
2024-07-18 8:16 ` Vlastimil Babka
2024-07-18 7:22 ` Barry Song
2024-07-18 7:27 ` Michal Hocko
2024-07-18 7:41 ` Barry Song
2024-07-18 7:53 ` Michal Hocko
2024-07-18 8:18 ` Barry Song
2024-07-18 8:32 ` Michal Hocko
2024-07-18 8:43 ` Barry Song
2024-07-18 8:50 ` Michal Hocko
2024-07-19 0:35 ` Barry Song
2024-07-19 7:02 ` Michal Hocko
2024-07-19 7:07 ` Barry Song
2024-07-19 7:42 ` Michal Hocko
2024-07-19 7:51 ` Barry Song
2024-07-19 8:01 ` Michal Hocko
2024-07-19 8:28 ` Barry Song
2024-07-19 8:40 ` Michal Hocko
2024-07-19 9:36 ` Barry Song
2024-07-19 9:45 ` Michal Hocko
2024-07-19 9:58 ` Barry Song
2024-07-19 10:57 ` Michal Hocko
2024-07-19 11:05 ` Barry Song
2024-07-19 11:19 ` Michal Hocko
2024-07-19 8:50 ` Vlastimil Babka
2024-07-19 9:33 ` Michal Hocko
2024-07-19 10:10 ` Vlastimil Babka
2024-07-19 10:52 ` Michal Hocko
2024-07-19 11:13 ` Vlastimil Babka
2024-07-19 11:26 ` Michal Hocko
2024-07-19 13:02 ` Barry Song
2024-07-19 13:30 ` Michal Hocko
2024-07-20 0:36 ` Barry Song
2024-07-22 7:23 ` Michal Hocko
2024-07-22 7:34 ` Vlastimil Babka
2024-07-19 7:37 ` Christoph Hellwig
2024-07-19 7:43 ` Barry Song
2024-07-19 7:53 ` Christoph Hellwig
2024-07-20 22:14 ` Barry Song
2024-07-22 7:26 ` Michal Hocko
2024-07-22 8:09 ` Barry Song
2024-07-22 9:01 ` Michal Hocko
2024-07-22 23:18 ` Christoph Hellwig
2024-07-22 23:22 ` Barry Song
2024-07-19 8:35 ` Vlastimil Babka
2024-07-18 7:48 ` Hailong Liu
2024-07-18 8:33 ` Barry Song
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=20240717230025.77361-1-21cnbao@gmail.com \
--to=21cnbao@gmail.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=hch@infradead.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=mhocko@suse.com \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=urezki@gmail.com \
--cc=v-songbaohua@oppo.com \
--cc=vbabka@suse.cz \
/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