linux-kernel - Re: [PATCH] sched/topology: Use kcalloc() in sched_init

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <bb6835e1-d6a7-4dd9-9c0e-f3d7794ac0a6@vivo.com>
Date: Thu, 28 Aug 2025 20:00:33 +0800
From: Qianfeng Rong <rongqianfeng@...o.com>
To: Valentin Schneider <vschneid@...hat.com>, Ingo Molnar <mingo@...hat.com>,
 Peter Zijlstra <peterz@...radead.org>, Juri Lelli <juri.lelli@...hat.com>,
 Vincent Guittot <vincent.guittot@...aro.org>,
 Dietmar Eggemann <dietmar.eggemann@....com>,
 Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>,
 Mel Gorman <mgorman@...e.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched/topology: Use kcalloc() in sched_init_numa()


在 2025/8/28 19:11, Valentin Schneider 写道:
> On 21/08/25 22:08, Qianfeng Rong wrote:
>> Replace kzalloc() with kcalloc() in sched_init_numa().  As noted in
>> the kernel documentation [1], open-coded multiplication in allocator
>> arguments is discouraged because it can lead to integer overflow.
>>
> Hm, checkpatch does warn about these.
>
>> Use kcalloc() to gain built-in overflow protection, making memory
>> allocation safer when calculating allocation size compared to explicit
>> multiplication. Similarly, use size_add() instead of explicit addition
>> for 'i + nr_levels + 1'.
>>
>> Link:
>> https://www.kernel.org/doc/html/next/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments
>> #1
> This document is actually in the kernel sources, it would be better to
> reference it as:
>
>    Documentation/process/deprecated.rst
I didn't notice this, thank you for the reminder.
>
>> @@ -1994,8 +1994,8 @@ void sched_init_numa(int offline_node)
>>        /* Compute default topology size */
>>        for (i = 0; sched_domain_topology[i].mask; i++);
>>
>> -	tl = kzalloc((i + nr_levels + 1) *
>> -			sizeof(struct sched_domain_topology_level), GFP_KERNEL);
>> +	tl = kcalloc(size_add(size_add(i, nr_levels), 1),
>> +		     sizeof(struct sched_domain_topology_level), GFP_KERNEL);
> @nr_levels is at most 256 (including illegal values between 0 and 9); @i is
> going to be the size of sched_domain_topology[]; is the double size_add()
> really warranted here?


You're right that the maximum value of nr_levels is fixed, and the double
size_add() to size_add() here are indeed unnecessary. I will submit the v2
version.

Best regards,
Qianfeng