Re: [PATCH] drm/solomon: Use kmalloc_array() instead of kmalloc()

Mehdi Ben Hadj Khelifa
2025-10-20T21:06:47Z

On 10/20/25 9:56 PM, Shuah Khan wrote:
> On 10/20/25 15:38, Mehdi Ben Hadj Khelifa wrote:
>> On 10/20/25 9:08 PM, Shuah Khan wrote:
>>> On 10/19/25 08:58, Mehdi Ben Hadj Khelifa wrote:
>>>> Replace kmalloc() with kmalloc_array() in several places to correctly
>>>> handle array allocations and benefit from built-in overflow checking.
>>>> This prevents potential integer overflows[1] when computing allocation
>>>> sizes from width, height, pitch, or page values.
>>>>
>>>> [1]:https://docs.kernel.org/process/deprecated.html
>>>
>>> Mu understanding is that this document lists deprecates APIs so people
>>> don't keep adding new ones.
>>>
>>> I didn't get the impression that we are supposed to go delete them from
>>> the kernel and cause a churn.
>>>
>> the document[1] specifically quotes the following:"
>> Dynamic size calculations (especially multiplication) should not be
>> performed in memory allocator (or similar) function arguments due to
>> the risk of them overflowing. This could lead to values wrapping
>> around and a smaller allocation being made than the caller was
>> expecting. Using those allocations could lead to linear overflows of
>> heap memory and other misbehaviors. (One exception to this is literal
>> values where the compiler can warn if they might overflow. However,
>> the preferred way in these cases is to refactor the code as suggested
>> below to avoid the open-coded arithmetic.)"
>> Specifically mentionned the refactor of the code base in such cases
>> which is why i'm doing the patches in the first place.Also i'm trying
>> the best to send patches related to the issue where such issues of
>> overflow are present or to be consistent with the same API used within
>> the same subsystem.
>> [1]:https://docs.kernel.org/process/deprecated.html> How are you
>> testing these changes - do you have this hardware?
>>>
>>>>
>> I have a raspberrypi zero 2 wh that i'm using in combination with the
>> ssd1306 OLED panel via I2C to test it's rendering and it's working
>> properly by using modetest and seeing no regressions or warnings in
>> dmesg.
>>
>
> Send v2 with all these details and why this change is needed
> in the first place.
>
Okay, I will do that as soon as possible.> When and how does this
potential problem trigger? Is this a
> theoretical or does this happen in this code path and how?
> Next time include all of these details people understand the
> problem better.
>
We'll do in the next iteration.Thanks

BR,
Mehdi> thanks,
> -- Shuah
>