[lvc-project] [Intel-wired-lan] [PATCH net-next v3] ice: Adjust over allocation of memory in ice_sched_add_root_node() and ice_sched_add_node()

Przemek Kitszel przemyslaw.kitszel at intel.com
Tue Jul 9 13:25:16 MSK 2024


On 7/9/24 11:50, Paul Menzel wrote:
> Dear Przemek,
> 
> 
> Thank you for your quick reply.
> 
> 
> Am 09.07.24 um 11:11 schrieb Przemek Kitszel:
>> On 7/9/24 10:54, Paul Menzel wrote:
>>> [Cc: -anirudh.venkataramanan at intel.com (Address rejected)]
>>>
>>> Am 09.07.24 um 10:49 schrieb Paul Menzel:
> 
>>>> Am 08.07.24 um 20:27 schrieb Aleksandr Mishin:
>>>>> In ice_sched_add_root_node() and ice_sched_add_node() there are 
>>>>> calls to
>>>>> devm_kcalloc() in order to allocate memory for array of pointers to
>>>>> 'ice_sched_node' structure. But incorrect types are used as sizeof()
>>>>> arguments in these calls (structures instead of pointers) which 
>>>>> leads to
>>>>> over allocation of memory.
>>>>
>>>> If you have the explicit size at hand, it’d be great if you added 
>>>> those to the commit message.
>>>>
>>>>> Adjust over allocation of memory by correcting types in devm_kcalloc()
>>>>> sizeof() arguments.
>>>>>
>>>>> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>>>>
>>>> Maybe mention, that Coverity found that too, and the warning was 
>>>> disabled, and use that commit in Fixes: tag? That’d be commit 
>>>> b36c598c999c (ice: Updates to Tx scheduler code), different from the 
>>>> one you used.
>>
>> this version does not have any SHA mentioned :)
> 
> Sorry, I don’t understand your answer. What SHA do you mean?

there is no commit cited by Aleksandr in v3, IIRC there was one in v1

I agree that mention would be valuable, and we still want v4 with my
Suggested-by dropped anyway :)

> 
>>>> `Documentation/process/submitting-patches.rst` says:
>>>>
>>>>> A Fixes: tag indicates that the patch fixes an issue in a previous
>>>>> commit. It is used to make it easy to determine where a bug
>>>>> originated, which can help review a bug fix. This tag also assists
>>>>> the stable kernel team in determining which stable kernel versions
>>>>> should receive your fix. This is the preferred method for indicating
>>>>> a bug fixed by the patch.
>>
>> so, this is not a "fix" per definition of a fix: "your patch changes
>> observable misbehavior"
>> If the over-allocation would be counted in megabytes, then it will
>> be a different case.
> 
> The quoted text just talks about “an issue”. What definition do you 
> refer to?

I mean that there is no issue (for the users), thus no fix.
Example of recently merged "not fix", with more links to other "non-
fixes":
https://lore.kernel.org/all/b836eb8ca8abf2f64478da48d250405bb1d90ad5.camel@sipsolutions.net/T/

> 
> 
> Kind regards,
> 
> Paul




More information about the lvc-project mailing list