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

[Thomas Zimmermann <tzimmermann@suse.de>]

Hi

Am 20.10.25 um 11:50 schrieb Jani Nikula:
> On Sun, 19 Oct 2025, Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@gmail.com> wrote:
>> On 10/19/25 3:47 PM, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 19.10.25 um 16:34 schrieb Greg KH:
>>>> On Sun, Oct 19, 2025 at 04:12:28PM +0100, Mehdi Ben Hadj Khelifa wrote:
>>>>> Replace kmalloc() with kmalloc_array() to correctly
>>>>> handle array allocations and benefit from built-in overflow checking[1].
>>>>>
>>>>> [1]:https://docs.kernel.org/process/deprecated.html
>>>>>
>>>>> Signed-off-by: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@gmail.com>
>>>>> ---
>>>>>    drivers/gpu/drm/tiny/repaper.c | 2 +-
>>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/tiny/repaper.c b/drivers/gpu/drm/tiny/
>>>>> repaper.c
>>>>> index 4824f863fdba..290132c24ff9 100644
>>>>> --- a/drivers/gpu/drm/tiny/repaper.c
>>>>> +++ b/drivers/gpu/drm/tiny/repaper.c
>>>>> @@ -534,7 +534,7 @@ static int repaper_fb_dirty(struct
>>>>> drm_framebuffer *fb, const struct iosys_map *
>>>>>        DRM_DEBUG("Flushing [FB:%d] st=%ums\n", fb->base.id,
>>>>>              epd->factored_stage_time);
>>>>> -    buf = kmalloc(fb->width * fb->height / 8, GFP_KERNEL);
>>>>> +    buf = kmalloc_array(fb->height / 8, fb->width, GFP_KERNEL);
> Also worth emphasizing that this is wildly wrong for any height that is
> not a multiple of 8.

Yes. I skipped over details as the format helpers would solve this 
problem if done correctly.

>
> And I thought I shot down a similar patch not long ago.

You did AFAIR.

>
> Is there some tool that suggests doing this? Fix the tool instead
> please.

There's this todo item that the patch refers to. Volunteers discover 
these and start working. But without mentoring, it's often not to 
anyone's benefit. I've noticed a similar pattern wrt the DRM todo list.

Best regards
Thomas

>
> BR,
> Jani.
>
>
>
>
>>>> This isn't an array, so this function change doesn't seem to make much
>>>> sense, right?  The size should have already been checked earlier in the
>>>> call change to be correct.
>> Yes,I was intending to say framebuffer but I was working on another
>> similar patch simultaneously so I reused same words by mistake. Thanks
>> for clarifying that.>
>>> Yes, we've recently received plenty of these pointless changes. The
>>> correct code would compute the number of bytes per pixel using
>>> drm_format_info_min_pitch() and multiply with fb->height. The latter
>>> could (maybe) use kmalloc_array(). It would still not be an array in the
>>> common sense.
>>>
>> Thanks for the review and suggestion.I will be sending a v2 patch with
>> the recommended code change.
>>
>> Best Regards,
>> Mehdi Ben Hadj Khelifa> Best regards
>>> Thomas
>>>
>>>> thanks,
>>>>
>>>> greg k-h
>>> -- 
>>> -- 
>>> Thomas Zimmermann
>>> Graphics Driver Developer
>>> SUSE Software Solutions Germany GmbH
>>> Frankenstrasse 146, 90461 Nuernberg, Germany
>>> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
>>> HRB 36809 (AG Nuernberg)

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)