[PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Deepak R Varma]

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

[PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Deepak R Varma]

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

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Mikko Perttunen]

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.

Mikko

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Mikko Perttunen]

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.

Mikko

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Deepak R Varma]

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

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Deepak R Varma]

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

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Mikko Perttunen]

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.

Mikko

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Mikko Perttunen]

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.

Mikko

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Deepak R Varma]

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?

Thanks again!
./drv




>
> Mikko

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Deepak R Varma]

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?

Thanks again!
./drv




>
> Mikko

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Mikko Perttunen]

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

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Mikko Perttunen]

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

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Deepak R Varma]

On Wed, Dec 28, 2022 at 03:48:05PM +0200, Mikko Perttunen wrote:
> 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:
> > >
> > > 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.

Sounds good. Thanks again. Would like to see if other experts have any further
guidance on this patch.

Regards,
./drv

>
> >
> > > Mikko
> >
> >
>

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Deepak R Varma]

On Wed, Dec 28, 2022 at 03:48:05PM +0200, Mikko Perttunen wrote:
> 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:
> > >
> > > 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.

Sounds good. Thanks again. Would like to see if other experts have any further
guidance on this patch.

Regards,
./drv

>
> >
> > > Mikko
> >
> >
>

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Stanislaw Gruszka]

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.

I agree with your point of view. But regarding this particular patch,
at least on code base I can see, after free_job_data label job_done
can not be NULL. So patch seems to be ok, but maybe changelog need to
be different

Regards
Stanislaw

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Stanislaw Gruszka]

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.

I agree with your point of view. But regarding this particular patch,
at least on code base I can see, after free_job_data label job_done
can not be NULL. So patch seems to be ok, but maybe changelog need to
be different

Regards
Stanislaw

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Mikko Perttunen]

On 12/30/22 11:15, Stanislaw Gruszka 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.
> 
> I agree with your point of view. But regarding this particular patch,
> at least on code base I can see, after free_job_data label job_done
> can not be NULL. So patch seems to be ok, but maybe changelog need to
> be different
> 
> Regards
> Stanislaw

It can be NULL; see:

         job->user_data = job_data;
         job->release = release_job;
         job->timeout = 10000;

         /*
          * job_data is now part of job reference counting, so don't release
          * it from here.
          */
         job_data = NULL;

If we go into free_job_data after this code (which happens if there is 
no error, or if host1x_job_submit fails), job_data will be NULL.

The memory is instead released in the 'put_job' label; host1x_job_put 
ends up calling release_job, which does the kfree.

(Yes, it is rather complicated..)

Thanks,
Mikko

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Mikko Perttunen]

On 12/30/22 11:15, Stanislaw Gruszka 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.
> 
> I agree with your point of view. But regarding this particular patch,
> at least on code base I can see, after free_job_data label job_done
> can not be NULL. So patch seems to be ok, but maybe changelog need to
> be different
> 
> Regards
> Stanislaw

It can be NULL; see:

         job->user_data = job_data;
         job->release = release_job;
         job->timeout = 10000;

         /*
          * job_data is now part of job reference counting, so don't release
          * it from here.
          */
         job_data = NULL;

If we go into free_job_data after this code (which happens if there is 
no error, or if host1x_job_submit fails), job_data will be NULL.

The memory is instead released in the 'put_job' label; host1x_job_put 
ends up calling release_job, which does the kfree.

(Yes, it is rather complicated..)

Thanks,
Mikko

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Mikko Perttunen]

On 12/30/22 12:01, Mikko Perttunen wrote:
> On 12/30/22 11:15, Stanislaw Gruszka 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.
>>
>> I agree with your point of view. But regarding this particular patch,
>> at least on code base I can see, after free_job_data label job_done
>> can not be NULL. So patch seems to be ok, but maybe changelog need to
>> be different
>>
>> Regards
>> Stanislaw
> 
> It can be NULL; see:
> 
>          job->user_data = job_data;
>          job->release = release_job;
>          job->timeout = 10000;
> 
>          /*
>           * job_data is now part of job reference counting, so don't 
> release
>           * it from here.
>           */
>          job_data = NULL;
> 
> If we go into free_job_data after this code (which happens if there is 
> no error, or if host1x_job_submit fails), job_data will be NULL.
> 
> The memory is instead released in the 'put_job' label; host1x_job_put 
> ends up calling release_job, which does the kfree.

Well, the refcount is dropped -- it's not necessarily freed immediately, 
if the job is in execution.

Mikko

> 
> (Yes, it is rather complicated..)
> 
> Thanks,
> Mikko

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Mikko Perttunen]

On 12/30/22 12:01, Mikko Perttunen wrote:
> On 12/30/22 11:15, Stanislaw Gruszka 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.
>>
>> I agree with your point of view. But regarding this particular patch,
>> at least on code base I can see, after free_job_data label job_done
>> can not be NULL. So patch seems to be ok, but maybe changelog need to
>> be different
>>
>> Regards
>> Stanislaw
> 
> It can be NULL; see:
> 
>          job->user_data = job_data;
>          job->release = release_job;
>          job->timeout = 10000;
> 
>          /*
>           * job_data is now part of job reference counting, so don't 
> release
>           * it from here.
>           */
>          job_data = NULL;
> 
> If we go into free_job_data after this code (which happens if there is 
> no error, or if host1x_job_submit fails), job_data will be NULL.
> 
> The memory is instead released in the 'put_job' label; host1x_job_put 
> ends up calling release_job, which does the kfree.

Well, the refcount is dropped -- it's not necessarily freed immediately, 
if the job is in execution.

Mikko

> 
> (Yes, it is rather complicated..)
> 
> Thanks,
> Mikko

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Deepak R Varma]

On Fri, Dec 30, 2022 at 12:03:25PM +0200, Mikko Perttunen wrote:
> On 12/30/22 12:01, Mikko Perttunen wrote:
> > On 12/30/22 11:15, Stanislaw Gruszka 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.
> > >
> > > I agree with your point of view. But regarding this particular patch,
> > > at least on code base I can see, after free_job_data label job_done
> > > can not be NULL. So patch seems to be ok, but maybe changelog need to
> > > be different
> > >
> > > Regards
> > > Stanislaw
> >
> > It can be NULL; see:
> >
> >          job->user_data = job_data;
> >          job->release = release_job;
> >          job->timeout = 10000;
> >
> >          /*
> >           * job_data is now part of job reference counting, so don't
> > release
> >           * it from here.
> >           */
> >          job_data = NULL;
> >
> > If we go into free_job_data after this code (which happens if there is
> > no error, or if host1x_job_submit fails), job_data will be NULL.
> >
> > The memory is instead released in the 'put_job' label; host1x_job_put
> > ends up calling release_job, which does the kfree.
>
> Well, the refcount is dropped -- it's not necessarily freed immediately, if
> the job is in execution.

Thanks Mikko. I Agree. Hence I think there is no change for the program at
runtime. The proposed change looks safe to me.

./drv

>
> Mikko
>
> >
> > (Yes, it is rather complicated..)
> >
> > Thanks,
> > Mikko
>

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Deepak R Varma]

On Fri, Dec 30, 2022 at 12:03:25PM +0200, Mikko Perttunen wrote:
> On 12/30/22 12:01, Mikko Perttunen wrote:
> > On 12/30/22 11:15, Stanislaw Gruszka 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.
> > >
> > > I agree with your point of view. But regarding this particular patch,
> > > at least on code base I can see, after free_job_data label job_done
> > > can not be NULL. So patch seems to be ok, but maybe changelog need to
> > > be different
> > >
> > > Regards
> > > Stanislaw
> >
> > It can be NULL; see:
> >
> >          job->user_data = job_data;
> >          job->release = release_job;
> >          job->timeout = 10000;
> >
> >          /*
> >           * job_data is now part of job reference counting, so don't
> > release
> >           * it from here.
> >           */
> >          job_data = NULL;
> >
> > If we go into free_job_data after this code (which happens if there is
> > no error, or if host1x_job_submit fails), job_data will be NULL.
> >
> > The memory is instead released in the 'put_job' label; host1x_job_put
> > ends up calling release_job, which does the kfree.
>
> Well, the refcount is dropped -- it's not necessarily freed immediately, if
> the job is in execution.

Thanks Mikko. I Agree. Hence I think there is no change for the program at
runtime. The proposed change looks safe to me.

./drv

>
> Mikko
>
> >
> > (Yes, it is rather complicated..)
> >
> > Thanks,
> > Mikko
>

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Deepak R Varma]

On Mon, Jan 02, 2023 at 11:50:36PM +0530, Deepak R Varma wrote:
> On Fri, Dec 30, 2022 at 12:03:25PM +0200, Mikko Perttunen wrote:
> > On 12/30/22 12:01, Mikko Perttunen wrote:
> > > On 12/30/22 11:15, Stanislaw Gruszka 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.
> > > >
> > > > I agree with your point of view. But regarding this particular patch,
> > > > at least on code base I can see, after free_job_data label job_done
> > > > can not be NULL. So patch seems to be ok, but maybe changelog need to
> > > > be different
> > > >
> > > > Regards
> > > > Stanislaw
> > >
> > > It can be NULL; see:
> > >
> > >          job->user_data = job_data;
> > >          job->release = release_job;
> > >          job->timeout = 10000;
> > >
> > >          /*
> > >           * job_data is now part of job reference counting, so don't
> > > release
> > >           * it from here.
> > >           */
> > >          job_data = NULL;
> > >
> > > If we go into free_job_data after this code (which happens if there is
> > > no error, or if host1x_job_submit fails), job_data will be NULL.
> > >
> > > The memory is instead released in the 'put_job' label; host1x_job_put
> > > ends up calling release_job, which does the kfree.
> >
> > Well, the refcount is dropped -- it's not necessarily freed immediately, if
> > the job is in execution.
> 
> Thanks Mikko. I Agree. Hence I think there is no change for the program at
> runtime. The proposed change looks safe to me.

Hello,
Requesting any further feedback/comment on this patch proposal.

Thank you,
./drv

> 
> ./drv
> 
> >
> > Mikko
> >
> > >
> > > (Yes, it is rather complicated..)
> > >
> > > Thanks,
> > > Mikko
> >

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Deepak R Varma]

On Mon, Jan 02, 2023 at 11:50:36PM +0530, Deepak R Varma wrote:
> On Fri, Dec 30, 2022 at 12:03:25PM +0200, Mikko Perttunen wrote:
> > On 12/30/22 12:01, Mikko Perttunen wrote:
> > > On 12/30/22 11:15, Stanislaw Gruszka 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.
> > > >
> > > > I agree with your point of view. But regarding this particular patch,
> > > > at least on code base I can see, after free_job_data label job_done
> > > > can not be NULL. So patch seems to be ok, but maybe changelog need to
> > > > be different
> > > >
> > > > Regards
> > > > Stanislaw
> > >
> > > It can be NULL; see:
> > >
> > >          job->user_data = job_data;
> > >          job->release = release_job;
> > >          job->timeout = 10000;
> > >
> > >          /*
> > >           * job_data is now part of job reference counting, so don't
> > > release
> > >           * it from here.
> > >           */
> > >          job_data = NULL;
> > >
> > > If we go into free_job_data after this code (which happens if there is
> > > no error, or if host1x_job_submit fails), job_data will be NULL.
> > >
> > > The memory is instead released in the 'put_job' label; host1x_job_put
> > > ends up calling release_job, which does the kfree.
> >
> > Well, the refcount is dropped -- it's not necessarily freed immediately, if
> > the job is in execution.
> 
> Thanks Mikko. I Agree. Hence I think there is no change for the program at
> runtime. The proposed change looks safe to me.

Hello,
Requesting any further feedback/comment on this patch proposal.

Thank you,
./drv

> 
> ./drv
> 
> >
> > Mikko
> >
> > >
> > > (Yes, it is rather complicated..)
> > >
> > > Thanks,
> > > Mikko
> >

Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree

[Stanislaw Gruszka]

On Fri, Dec 30, 2022 at 12:01:23PM +0200, Mikko Perttunen wrote:
> On 12/30/22 11:15, Stanislaw Gruszka 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.
> > 
> > I agree with your point of view. But regarding this particular patch,
> > at least on code base I can see, after free_job_data label job_done
> > can not be NULL. So patch seems to be ok, but maybe changelog need to
> > be different
> > 
> > Regards
> > Stanislaw
> 
> It can be NULL; see:
> 
>         job->user_data = job_data;
>         job->release = release_job;
>         job->timeout = 10000;
> 
>         /*
>          * job_data is now part of job reference counting, so don't release
>          * it from here.
>          */
>         job_data = NULL;
> 
> If we go into free_job_data after this code (which happens if there is no
> error, or if host1x_job_submit fails), job_data will be NULL.
> 
> The memory is instead released in the 'put_job' label; host1x_job_put ends
> up calling release_job, which does the kfree.
> 
> (Yes, it is rather complicated..)

Ok, then better to keep the check.

Regards
Stanislaw