All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@gmail.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Greg KH <gregkh@linuxfoundation.org>
Cc: lanzano.alex@gmail.com, maarten.lankhorst@linux.intel.com,
	mripard@kernel.org, airlied@gmail.com, simona@ffwll.ch,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	skhan@linuxfoundation.org, david.hunter.linux@gmail.com,
	khalid@kernel.org,
	linux-kernel-mentees@lists.linuxfoundation.org
Subject: Re: [PATCH] drm/tiny: Use kmalloc_array() instead of kmalloc()
Date: Mon, 20 Oct 2025 12:50:04 +0300	[thread overview]
Message-ID: <02e617bec795d2ef371069f2d5fb954dfb31a450@intel.com> (raw)
In-Reply-To: <d072dfe7-e0e9-49f6-89ed-25d194035e3b@gmail.com>

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.

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

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

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)
>

-- 
Jani Nikula, Intel

  reply	other threads:[~2025-10-20  9:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-19 15:12 [PATCH] drm/tiny: Use kmalloc_array() instead of kmalloc() Mehdi Ben Hadj Khelifa
2025-10-19 14:34 ` Greg KH
2025-10-19 14:47   ` Thomas Zimmermann
2025-10-19 16:03     ` Mehdi Ben Hadj Khelifa
2025-10-20  9:50       ` Jani Nikula [this message]
2025-10-20 10:49         ` Thomas Zimmermann
2025-10-20 20:06         ` Shuah Khan
2025-10-20 21:11           ` Mehdi Ben Hadj Khelifa
2025-10-20 20:22             ` Shuah Khan
2025-10-20 20:22             ` Shuah Khan
2025-10-20 22:00               ` Mehdi Ben Hadj Khelifa
  -- strict thread matches above, loose matches on Subject: below --
2025-09-23 11:00 Rahul Kumar
2025-09-23 13:51 ` Jani Nikula
2025-09-24  6:07   ` Rahul Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=02e617bec795d2ef371069f2d5fb954dfb31a450@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=airlied@gmail.com \
    --cc=david.hunter.linux@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=khalid@kernel.org \
    --cc=lanzano.alex@gmail.com \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mehdi.benhadjkhelifa@gmail.com \
    --cc=mripard@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=skhan@linuxfoundation.org \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.