Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 28 Dec 2022 19:48:35 +0530
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
Message-ID: <Y6xQO+w/P+m8w6ke@qemulion>
References: <Y6sn7XptKyk5cbrA@qemulion>
 <864f2fdd-4289-a178-bbf1-c2a6a579c58c@kapsi.fi>
 <Y6w/4IzoMFsVnCmu@qemulion>
 <280170a7-de12-f362-cda3-11208ead0a88@kapsi.fi>
 <Y6xF6q6qj+ggEdgN@qemulion>
 <1453f93b-f6ad-04d8-c493-6c8d2a3678bd@kapsi.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1453f93b-f6ad-04d8-c493-6c8d2a3678bd@kapsi.fi>
Precedence: bulk

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