lkml.org 
[lkml]   [2022]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree
From
On 12/28/22 15:34, Deepak R Varma wrote:
> On Wed, Dec 28, 2022 at 03:17:59PM +0200, Mikko Perttunen wrote:
>> On 12/28/22 15:08, Deepak R Varma wrote:
>>> On Wed, Dec 28, 2022 at 02:28:54PM +0200, Mikko Perttunen wrote:
>>>> On 12/27/22 19:14, Deepak R Varma wrote:
>>>>> kfree() & vfree() internally perform NULL check on the pointer handed
>>>>> to it and take no action if it indeed is NULL. Hence there is no need
>>>>> for a pre-check of the memory pointer before handing it to
>>>>> kfree()/vfree().
>>>>>
>>>>> Issue reported by ifnullfree.cocci Coccinelle semantic patch script.
>>>>>
>>>>> Signed-off-by: Deepak R Varma <drv@mailo.com>
>>>>> ---
>>>>> drivers/gpu/drm/tegra/submit.c | 4 ++--
>>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/tegra/submit.c b/drivers/gpu/drm/tegra/submit.c
>>>>> index 066f88564169..06f836db99d0 100644
>>>>> --- a/drivers/gpu/drm/tegra/submit.c
>>>>> +++ b/drivers/gpu/drm/tegra/submit.c
>>>>> @@ -680,8 +680,8 @@ int tegra_drm_ioctl_channel_submit(struct drm_device *drm, void *data,
>>>>> kfree(job_data->used_mappings);
>>>>> }
>>>>>
>>>>> - if (job_data)
>>>>> - kfree(job_data);
>>>>> + kfree(job_data);
>>>>> +
>>>>> put_bo:
>>>>> gather_bo_put(&bo->base);
>>>>> unlock:
>>>>> --
>>>>> 2.34.1
>>>>>
>>>>>
>>>>>
>>>>
>>>> It continues to be the case that I think this transform is bad. Same applies
>>>> to the host1x patch.
>>>
>>> Hello Mikko,
>>> Thank you for responding to the patch proposal. Could you please explain why is
>>> this bad?
>>>
>>> Regards,
>>> ./drv
>>>
>>>>
>>>> Mikko
>>>
>>>
>>
>> Hi,
>>
>> it gets rid of visual hints on code paths indicating the possible liveness
>> of pointer variables. I.e., after the change, whether the pointer can be
>> NULL or not is more difficult to reason about locally, instead requiring
>> more global reasoning which is mentally more taxing.
>>
>> Since C's type system doesn't help with tracking these kinds of things, I
>> believe it is important to have these kinds of local contextual cues to help
>> the programmer.
>
> Hello Mikko,
> That really helps. Thank you for the detailed explanation. I do have an extended
> question though. In this context, when we are ready to release the memory, how
> is it useful to know if it is NULL or not this late in the flow when the scope
> is about to end?

In the current code it doesn't matter, but if someone went to change
this code (for example to add another release step), and we just had
'kfree(job_data)', they would have to remember that kfree works with
NULL pointers, and would have to go looking elsewhere in the code to see
if it is in fact possible to assume that job_data cannot be NULL here,
or not. If they forget about kfree working with NULL pointers, which
wouldn't be that surprising since it is almost always only called with
non-NULL pointers, they might instead introduce a bug.

In this particular instance it's probably not that bad since immediately
above we have another 'if' block that checks if job_data is NULL, which
serves as a hint to the programmer; however, as a general principle it
stands that having the NULL check here makes it obvious to any reading
programmer that they any changes they make have to consider if the
pointer is NULL or not.

>
> Thanks again!
> ./drv
>

Thanks!
Mikko

>
>
>
>>
>> Mikko
>
>

\
 
 \ /
  Last update: 2023-03-26 23:22    [W:0.074 / U:0.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site