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;
Message-ID: <f403d196-352f-ee04-8568-d6600924af0f@kapsi.fi>
Date:   Wed, 13 Apr 2022 10:22:08 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.4.1
Subject: Re: [PATCH] drm/tegra: remove useless if check before kfree
Content-Language: en-US
To:     Bernard Zhao <zhaojunkui2008@126.com>,
        Thierry Reding <thierry.reding@gmail.com>,
        David Airlie <airlied@linux.ie>,
        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
Cc:     bernard@vivo.com
References: <20220413064618.23974-1-zhaojunkui2008@126.com>
From:   Mikko Perttunen <cyndis@kapsi.fi>
In-Reply-To: <20220413064618.23974-1-zhaojunkui2008@126.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 4/13/22 09:46, Bernard Zhao wrote:
> This patch remove useless if check before kfree.
> 
> Signed-off-by: Bernard Zhao <zhaojunkui2008@126.com>
> ---
>   drivers/gpu/drm/tegra/submit.c | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tegra/submit.c b/drivers/gpu/drm/tegra/submit.c
> index 6d6dd8c35475..54ac31bc80f6 100644
> --- a/drivers/gpu/drm/tegra/submit.c
> +++ b/drivers/gpu/drm/tegra/submit.c
> @@ -639,8 +639,7 @@ 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:

(Same comment as for other patch.)

I personally dislike leaving the NULL checks off with calls to kfree. 
With the NULL check there, while reading the code it is obvious that the 
intention is that the value can be either a valid pointer or NULL. IMHO 
with C's type system/conventions we need this kind of contextual 
information to understand the code easily and avoid bugs.

Mikko