* [PATCH] rcuscale: using kmalloc_array() to relpace kmalloc()
@ 2025-04-21 6:15 Su Hui
2025-04-21 13:49 ` Paul E. McKenney
2025-04-22 1:51 ` [PATCH v2] rcuscale: using kcalloc() " Su Hui
0 siblings, 2 replies; 6+ messages in thread
From: Su Hui @ 2025-04-21 6:15 UTC (permalink / raw)
To: dave, paulmck, josh, frederic, neeraj.upadhyay, joel, boqun.feng,
urezki, rostedt, mathieu.desnoyers, jiangshanlai, qiang.zhang1211
Cc: Su Hui, linux-kernel, rcu, kernel-janitors, linux-hardening
It's safer to using kmalloc_array() because it can prevent overflow
problem.
Signed-off-by: Su Hui <suhui@nfschina.com>
---
kernel/rcu/rcuscale.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/rcuscale.c b/kernel/rcu/rcuscale.c
index 0f3059b1b80d..cbe2195f08d6 100644
--- a/kernel/rcu/rcuscale.c
+++ b/kernel/rcu/rcuscale.c
@@ -762,7 +762,7 @@ kfree_scale_thread(void *arg)
}
for (i = 0; i < kfree_alloc_num; i++) {
- alloc_ptr = kmalloc(kfree_mult * sizeof(struct kfree_obj), GFP_KERNEL);
+ alloc_ptr = kmalloc_array(kfree_mult, sizeof(struct kfree_obj), GFP_KERNEL);
if (!alloc_ptr)
return -ENOMEM;
--
2.30.2
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH] rcuscale: using kmalloc_array() to relpace kmalloc()
2025-04-21 6:15 [PATCH] rcuscale: using kmalloc_array() to relpace kmalloc() Su Hui
@ 2025-04-21 13:49 ` Paul E. McKenney
2025-04-22 1:37 ` Su Hui
2025-04-22 1:51 ` [PATCH v2] rcuscale: using kcalloc() " Su Hui
1 sibling, 1 reply; 6+ messages in thread
From: Paul E. McKenney @ 2025-04-21 13:49 UTC (permalink / raw)
To: Su Hui
Cc: dave, josh, frederic, neeraj.upadhyay, joel, boqun.feng, urezki,
rostedt, mathieu.desnoyers, jiangshanlai, qiang.zhang1211,
linux-kernel, rcu, kernel-janitors, linux-hardening
On Mon, Apr 21, 2025 at 02:15:09PM +0800, Su Hui wrote:
> It's safer to using kmalloc_array() because it can prevent overflow
> problem.
>
> Signed-off-by: Su Hui <suhui@nfschina.com>
Thank you!
But isn't kcalloc just a wrapper around kmalloc_array() anyway?
Thanx, Paul
> ---
> kernel/rcu/rcuscale.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/rcu/rcuscale.c b/kernel/rcu/rcuscale.c
> index 0f3059b1b80d..cbe2195f08d6 100644
> --- a/kernel/rcu/rcuscale.c
> +++ b/kernel/rcu/rcuscale.c
> @@ -762,7 +762,7 @@ kfree_scale_thread(void *arg)
> }
>
> for (i = 0; i < kfree_alloc_num; i++) {
> - alloc_ptr = kmalloc(kfree_mult * sizeof(struct kfree_obj), GFP_KERNEL);
> + alloc_ptr = kmalloc_array(kfree_mult, sizeof(struct kfree_obj), GFP_KERNEL);
> if (!alloc_ptr)
> return -ENOMEM;
>
> --
> 2.30.2
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] rcuscale: using kmalloc_array() to relpace kmalloc()
2025-04-21 13:49 ` Paul E. McKenney
@ 2025-04-22 1:37 ` Su Hui
0 siblings, 0 replies; 6+ messages in thread
From: Su Hui @ 2025-04-22 1:37 UTC (permalink / raw)
To: paulmck
Cc: dave, josh, frederic, neeraj.upadhyay, joel, boqun.feng, urezki,
rostedt, mathieu.desnoyers, jiangshanlai, qiang.zhang1211,
linux-kernel, rcu, kernel-janitors, linux-hardening
On 2025/4/21 21:49, Paul E. McKenney wrote:
> On Mon, Apr 21, 2025 at 02:15:09PM +0800, Su Hui wrote:
>> It's safer to using kmalloc_array() because it can prevent overflow
>> problem.
>>
>> Signed-off-by: Su Hui <suhui@nfschina.com>
> Thank you!
>
> But isn't kcalloc just a wrapper around kmalloc_array() anyway?
Yes, and kcalloc() add the _GFP_ZERO flag. I can send a v2 patch with
kcalloc().
Thanks for your suggestion.
Su Hui
>> ---
>> kernel/rcu/rcuscale.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/rcu/rcuscale.c b/kernel/rcu/rcuscale.c
>> index 0f3059b1b80d..cbe2195f08d6 100644
>> --- a/kernel/rcu/rcuscale.c
>> +++ b/kernel/rcu/rcuscale.c
>> @@ -762,7 +762,7 @@ kfree_scale_thread(void *arg)
>> }
>>
>> for (i = 0; i < kfree_alloc_num; i++) {
>> - alloc_ptr = kmalloc(kfree_mult * sizeof(struct kfree_obj), GFP_KERNEL);
>> + alloc_ptr = kmalloc_array(kfree_mult, sizeof(struct kfree_obj), GFP_KERNEL);
>> if (!alloc_ptr)
>> return -ENOMEM;
>>
>> --
>> 2.30.2
>>
>>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v2] rcuscale: using kcalloc() to relpace kmalloc()
2025-04-21 6:15 [PATCH] rcuscale: using kmalloc_array() to relpace kmalloc() Su Hui
2025-04-21 13:49 ` Paul E. McKenney
@ 2025-04-22 1:51 ` Su Hui
2025-04-22 17:58 ` Paul E. McKenney
1 sibling, 1 reply; 6+ messages in thread
From: Su Hui @ 2025-04-22 1:51 UTC (permalink / raw)
To: dave, paulmck, josh, frederic, neeraj.upadhyay, joel, boqun.feng,
urezki, rostedt, mathieu.desnoyers, jiangshanlai, qiang.zhang1211
Cc: Su Hui, linux-kernel, rcu, kernel-janitors, linux-hardening
It's safer to using kcalloc() because it can prevent overflow
problem.
Signed-off-by: Su Hui <suhui@nfschina.com>
---
v2:
- using kcalloc rather than kmalloc_array().
v1:
- https://lore.kernel.org/all/20250421061508.718752-1-suhui@nfschina.com/
kernel/rcu/rcuscale.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/rcuscale.c b/kernel/rcu/rcuscale.c
index 0f3059b1b80d..b521d0455992 100644
--- a/kernel/rcu/rcuscale.c
+++ b/kernel/rcu/rcuscale.c
@@ -762,7 +762,7 @@ kfree_scale_thread(void *arg)
}
for (i = 0; i < kfree_alloc_num; i++) {
- alloc_ptr = kmalloc(kfree_mult * sizeof(struct kfree_obj), GFP_KERNEL);
+ alloc_ptr = kcalloc(kfree_mult, sizeof(struct kfree_obj), GFP_KERNEL);
if (!alloc_ptr)
return -ENOMEM;
--
2.30.2
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH v2] rcuscale: using kcalloc() to relpace kmalloc()
2025-04-22 1:51 ` [PATCH v2] rcuscale: using kcalloc() " Su Hui
@ 2025-04-22 17:58 ` Paul E. McKenney
2025-04-22 22:55 ` Joel Fernandes
0 siblings, 1 reply; 6+ messages in thread
From: Paul E. McKenney @ 2025-04-22 17:58 UTC (permalink / raw)
To: Su Hui
Cc: dave, josh, frederic, neeraj.upadhyay, joel, boqun.feng, urezki,
rostedt, mathieu.desnoyers, jiangshanlai, qiang.zhang1211,
linux-kernel, rcu, kernel-janitors, linux-hardening
On Tue, Apr 22, 2025 at 09:51:45AM +0800, Su Hui wrote:
> It's safer to using kcalloc() because it can prevent overflow
> problem.
>
> Signed-off-by: Su Hui <suhui@nfschina.com>
Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> ---
> v2:
> - using kcalloc rather than kmalloc_array().
> v1:
> - https://lore.kernel.org/all/20250421061508.718752-1-suhui@nfschina.com/
>
> kernel/rcu/rcuscale.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/rcu/rcuscale.c b/kernel/rcu/rcuscale.c
> index 0f3059b1b80d..b521d0455992 100644
> --- a/kernel/rcu/rcuscale.c
> +++ b/kernel/rcu/rcuscale.c
> @@ -762,7 +762,7 @@ kfree_scale_thread(void *arg)
> }
>
> for (i = 0; i < kfree_alloc_num; i++) {
> - alloc_ptr = kmalloc(kfree_mult * sizeof(struct kfree_obj), GFP_KERNEL);
> + alloc_ptr = kcalloc(kfree_mult, sizeof(struct kfree_obj), GFP_KERNEL);
> if (!alloc_ptr)
> return -ENOMEM;
>
> --
> 2.30.2
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH v2] rcuscale: using kcalloc() to relpace kmalloc()
2025-04-22 17:58 ` Paul E. McKenney
@ 2025-04-22 22:55 ` Joel Fernandes
0 siblings, 0 replies; 6+ messages in thread
From: Joel Fernandes @ 2025-04-22 22:55 UTC (permalink / raw)
To: paulmck, Su Hui
Cc: dave, josh, frederic, neeraj.upadhyay, joel, boqun.feng, urezki,
rostedt, mathieu.desnoyers, jiangshanlai, qiang.zhang1211,
linux-kernel, rcu, kernel-janitors, linux-hardening
On 4/22/2025 1:58 PM, Paul E. McKenney wrote:
> On Tue, Apr 22, 2025 at 09:51:45AM +0800, Su Hui wrote:
>> It's safer to using kcalloc() because it can prevent overflow
>> problem.
>>
>> Signed-off-by: Su Hui <suhui@nfschina.com>
>
> Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
Applied, thanks.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2025-04-22 22:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-04-21 6:15 [PATCH] rcuscale: using kmalloc_array() to relpace kmalloc() Su Hui
2025-04-21 13:49 ` Paul E. McKenney
2025-04-22 1:37 ` Su Hui
2025-04-22 1:51 ` [PATCH v2] rcuscale: using kcalloc() " Su Hui
2025-04-22 17:58 ` Paul E. McKenney
2025-04-22 22:55 ` Joel Fernandes
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).