Linux Tegra architecture development
 help / color / mirror / Atom feed
From: Deepak R Varma <drv@mailo.com>
To: Mikko Perttunen <cyndis@kapsi.fi>
Cc: Thierry Reding <thierry.reding@gmail.com>,
	David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Saurabh Singh Sengar <ssengar@microsoft.com>,
	Praveen Kumar <kumarpraveen@linux.microsoft.com>,
	Deepak R Varma <drv@mailo.com>
Subject: Re: [PATCH] drm/tegra: submit: No need for Null pointer check before kfree
Date: Wed, 28 Dec 2022 19:04:34 +0530	[thread overview]
Message-ID: <Y6xF6q6qj+ggEdgN@qemulion> (raw)
In-Reply-To: <280170a7-de12-f362-cda3-11208ead0a88@kapsi.fi>

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



  reply	other threads:[~2022-12-28 13:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-27 17:14 [PATCH] drm/tegra: submit: No need for Null pointer check before kfree Deepak R Varma
2022-12-28 12:28 ` Mikko Perttunen
     [not found]   ` <Y6w/4IzoMFsVnCmu@qemulion>
2022-12-28 13:17     ` Mikko Perttunen
2022-12-28 13:34       ` Deepak R Varma [this message]
2022-12-28 13:48         ` Mikko Perttunen
2022-12-28 14:18           ` Deepak R Varma
2022-12-30  9:15       ` Stanislaw Gruszka
2022-12-30 10:01         ` Mikko Perttunen
2022-12-30 10:03           ` Mikko Perttunen
2023-01-02 18:20             ` Deepak R Varma
2023-01-22 18:18               ` Deepak R Varma
2022-12-30 10:15           ` Stanislaw Gruszka

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=Y6xF6q6qj+ggEdgN@qemulion \
    --to=drv@mailo.com \
    --cc=airlied@gmail.com \
    --cc=cyndis@kapsi.fi \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jonathanh@nvidia.com \
    --cc=kumarpraveen@linux.microsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=ssengar@microsoft.com \
    --cc=thierry.reding@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox