[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <989ace7c-92a3-438e-a0a6-3cbeb46adba6@gmail.com>
Date: Tue, 23 Sep 2025 09:20:09 +0100
From: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@...il.com>
To: Thomas Zimmermann <tzimmermann@...e.de>,
maarten.lankhorst@...ux.intel.com, mripard@...nel.org, airlied@...il.com,
simona@...ll.ch, mingo@...nel.org, tglx@...utronix.de, jfalempe@...hat.com,
Shuah Khan <skhan@...uxfoundation.org>, david.hunter.linux@...il.com,
rubenru09@....com
Cc: dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
linux-kernel-mentees@...ts.linuxfoundation.org
Subject: Re: [PATCH] drm/gud: Use kmalloc_array() instead of kmalloc()
On 9/23/25 8:06 AM, Thomas Zimmermann wrote:
> Hi
>
> Am 23.09.25 um 08:34 schrieb Thomas Zimmermann:
>> cc Ruben
>>
>> Am 22.09.25 um 19:43 schrieb Mehdi Ben Hadj Khelifa:
>>> Replace kmalloc with kmalloc array in drm/gud/gud_pipe.c since the
>>> calculation inside kmalloc is dynamic "width * height" and added
>>> u_char as the size of each element.
>>>
>>> Signed-off-by: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@...il.com>
>>> ---
>>> drivers/gpu/drm/gud/gud_pipe.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/
>>> gud_pipe.c
>>> index 8d548d08f127..eeea0cb4c7aa 100644
>>> --- a/drivers/gpu/drm/gud/gud_pipe.c
>>> +++ b/drivers/gpu/drm/gud/gud_pipe.c
>>> @@ -70,7 +70,7 @@ static size_t gud_xrgb8888_to_r124(u8 *dst, const
>>> struct drm_format_info *format
>>> height = drm_rect_height(rect);
>>> len = drm_format_info_min_pitch(format, 0, width) * height;
>>> - buf = kmalloc(width * height, GFP_KERNEL);
>>> + buf = kmalloc_array(width * height, sizeof(u_char), GFP_KERNEL);
>
> u_char is more or less guaranteed to be 8 bit. So what's the point?
i thought it would be more "clean" to have a data type that is of 1 byte
size to use as a reference for the size of each element here.
> There's a potential overflow in width * height. If anything, you want to
> call kmalloc_array(height, width).
This was more apparent to me after i have sent the patch and was waiting
for a reply first. Since my initial though was that width or height
alone couldn't be treated as a reference to "n of elements" or "size of
each element" but your suggestion is more logical since leaving the
calculation width * height in the kmalloc_array would defeat the purpose
of switching from kmalloc to kmalloc_array since dynamic calculation is
still present and overflow is still possible.
I will send a v2 patch shortly changing to your suggestion.
> Best regards
> Thomas
>
Best Regards,
Mehdi Ben Hadj Khelifa
Powered by blists - more mailing lists