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

[Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@gmail.com>]

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
>