* [PATCH] mm/vmalloc: Use kmalloc_array() instead of kmalloc()
@ 2025-10-18 20:11 Mehdi Ben Hadj Khelifa
2025-10-20 9:56 ` Uladzislau Rezki
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Mehdi Ben Hadj Khelifa @ 2025-10-18 20:11 UTC (permalink / raw)
To: akpm, urezki
Cc: linux-mm, linux-kernel, skhan, david.hunter.linux,
linux-kernel-mentees, khalid, Mehdi Ben Hadj Khelifa
The number of NUMA nodes (nr_node_ids) is bounded, so overflow is not a
practical concern here. However, using kmalloc_array() better reflects the
intent to allocate an array of unsigned ints, and improves consistency with
other NUMA-related allocations.
No functional change intended.
Signed-off-by: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@gmail.com>
---
mm/vmalloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 798b2ed21e46..697bc171b013 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -5055,7 +5055,7 @@ static int vmalloc_info_show(struct seq_file *m, void *p)
unsigned int *counters;
if (IS_ENABLED(CONFIG_NUMA))
- counters = kmalloc(nr_node_ids * sizeof(unsigned int), GFP_KERNEL);
+ counters = kmalloc_array(nr_node_ids, sizeof(unsigned int), GFP_KERNEL);
for_each_vmap_node(vn) {
spin_lock(&vn->busy.lock);
--
2.51.1.dirty
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] mm/vmalloc: Use kmalloc_array() instead of kmalloc()
2025-10-18 20:11 [PATCH] mm/vmalloc: Use kmalloc_array() instead of kmalloc() Mehdi Ben Hadj Khelifa
@ 2025-10-20 9:56 ` Uladzislau Rezki
2025-10-20 11:10 ` Vishal Moola (Oracle)
2025-10-20 15:29 ` Khalid Aziz
2 siblings, 0 replies; 4+ messages in thread
From: Uladzislau Rezki @ 2025-10-20 9:56 UTC (permalink / raw)
To: Mehdi Ben Hadj Khelifa
Cc: akpm, urezki, linux-mm, linux-kernel, skhan, david.hunter.linux,
linux-kernel-mentees, khalid
On Sat, Oct 18, 2025 at 09:11:48PM +0100, Mehdi Ben Hadj Khelifa wrote:
> The number of NUMA nodes (nr_node_ids) is bounded, so overflow is not a
> practical concern here. However, using kmalloc_array() better reflects the
> intent to allocate an array of unsigned ints, and improves consistency with
> other NUMA-related allocations.
>
> No functional change intended.
>
> Signed-off-by: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@gmail.com>
> ---
> mm/vmalloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 798b2ed21e46..697bc171b013 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -5055,7 +5055,7 @@ static int vmalloc_info_show(struct seq_file *m, void *p)
> unsigned int *counters;
>
> if (IS_ENABLED(CONFIG_NUMA))
> - counters = kmalloc(nr_node_ids * sizeof(unsigned int), GFP_KERNEL);
> + counters = kmalloc_array(nr_node_ids, sizeof(unsigned int), GFP_KERNEL);
>
> for_each_vmap_node(vn) {
> spin_lock(&vn->busy.lock);
> --
> 2.51.1.dirty
>
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Thank you!
--
Uladzislau Rezki
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] mm/vmalloc: Use kmalloc_array() instead of kmalloc()
2025-10-18 20:11 [PATCH] mm/vmalloc: Use kmalloc_array() instead of kmalloc() Mehdi Ben Hadj Khelifa
2025-10-20 9:56 ` Uladzislau Rezki
@ 2025-10-20 11:10 ` Vishal Moola (Oracle)
2025-10-20 15:29 ` Khalid Aziz
2 siblings, 0 replies; 4+ messages in thread
From: Vishal Moola (Oracle) @ 2025-10-20 11:10 UTC (permalink / raw)
To: Mehdi Ben Hadj Khelifa
Cc: akpm, urezki, linux-mm, linux-kernel, skhan, david.hunter.linux,
linux-kernel-mentees, khalid
On Sat, Oct 18, 2025 at 09:11:48PM +0100, Mehdi Ben Hadj Khelifa wrote:
> The number of NUMA nodes (nr_node_ids) is bounded, so overflow is not a
> practical concern here. However, using kmalloc_array() better reflects the
> intent to allocate an array of unsigned ints, and improves consistency with
> other NUMA-related allocations.
>
> No functional change intended.
>
> Signed-off-by: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@gmail.com>
> ---
Reviewed-by: Vishal Moola (Oracle) <vishal.moola@gmail.com>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] mm/vmalloc: Use kmalloc_array() instead of kmalloc()
2025-10-18 20:11 [PATCH] mm/vmalloc: Use kmalloc_array() instead of kmalloc() Mehdi Ben Hadj Khelifa
2025-10-20 9:56 ` Uladzislau Rezki
2025-10-20 11:10 ` Vishal Moola (Oracle)
@ 2025-10-20 15:29 ` Khalid Aziz
2 siblings, 0 replies; 4+ messages in thread
From: Khalid Aziz @ 2025-10-20 15:29 UTC (permalink / raw)
To: Mehdi Ben Hadj Khelifa, akpm, urezki
Cc: linux-mm, linux-kernel, skhan, david.hunter.linux,
linux-kernel-mentees
On 10/18/25 2:11 PM, Mehdi Ben Hadj Khelifa wrote:
> The number of NUMA nodes (nr_node_ids) is bounded, so overflow is not a
> practical concern here. However, using kmalloc_array() better reflects the
> intent to allocate an array of unsigned ints, and improves consistency with
> other NUMA-related allocations.
>
> No functional change intended.
>
> Signed-off-by: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@gmail.com>
> ---
> mm/vmalloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 798b2ed21e46..697bc171b013 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -5055,7 +5055,7 @@ static int vmalloc_info_show(struct seq_file *m, void *p)
> unsigned int *counters;
>
> if (IS_ENABLED(CONFIG_NUMA))
> - counters = kmalloc(nr_node_ids * sizeof(unsigned int), GFP_KERNEL);
> + counters = kmalloc_array(nr_node_ids, sizeof(unsigned int), GFP_KERNEL);
>
> for_each_vmap_node(vn) {
> spin_lock(&vn->busy.lock);
This looks like reasonable change for clarity.
Reviewed-by: Khalid Aziz <khalid@kernel.org>
--
Khalid
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-10-20 15:29 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-10-18 20:11 [PATCH] mm/vmalloc: Use kmalloc_array() instead of kmalloc() Mehdi Ben Hadj Khelifa
2025-10-20 9:56 ` Uladzislau Rezki
2025-10-20 11:10 ` Vishal Moola (Oracle)
2025-10-20 15:29 ` Khalid Aziz
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).