Received-SPF: pass (google.com: domain of linux-kernel+bounces-182045-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <af6cad98-fde0-440d-8d26-05045387df08@collabora.com>
Date: Fri, 17 May 2024 13:23:22 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] drm/mediatek/dp: fix spurious kfree()
To: Michael Walle <mwalle@kernel.org>, Chun-Kuang Hu
 <chunkuang.hu@kernel.org>, Philipp Zabel <p.zabel@pengutronix.de>,
 David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
 Matthias Brugger <matthias.bgg@gmail.com>
Cc: Jani Nikula <jani.nikula@intel.com>, Chen-Yu Tsai <wenst@chromium.org>,
 linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
 linux-arm-kernel@lists.infradead.org
References: <20240517093024.1702750-1-mwalle@kernel.org>
 <de0191f3-271b-4f0e-aa73-910543587c9d@collabora.com>
 <D1BVE3G40OVL.3KX13LU75M122@kernel.org>
 <0d8f89d4-e16e-4c8d-b983-38df8fcc387e@collabora.com>
 <D1BVPABXTSPH.22ML1GLOMHEJR@kernel.org>
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Content-Language: en-US
In-Reply-To: <D1BVPABXTSPH.22ML1GLOMHEJR@kernel.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Il 17/05/24 13:21, Michael Walle ha scritto:
> On Fri May 17, 2024 at 1:09 PM CEST, AngeloGioacchino Del Regno wrote:
>> Il 17/05/24 13:07, Michael Walle ha scritto:
>>> On Fri May 17, 2024 at 12:35 PM CEST, AngeloGioacchino Del Regno wrote:
>>>> Il 17/05/24 11:30, Michael Walle ha scritto:
>>>>> drm_edid_to_sad() might return an error or just zero. If that is the
>>>>> case, we must not free the SADs because there was no allocation in
>>>>> the first place.
>>>>>
>>>>> Fixes: dab12fa8d2bd ("drm/mediatek/dp: fix memory leak on ->get_edid callback audio detection")
>>>>> Signed-off-by: Michael Walle <mwalle@kernel.org>
>>>>> ---
>>>>>     drivers/gpu/drm/mediatek/mtk_dp.c | 10 ++++++++--
>>>>>     1 file changed, 8 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
>>>>> index 536366956447..ada12927bbac 100644
>>>>> --- a/drivers/gpu/drm/mediatek/mtk_dp.c
>>>>> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
>>>>> @@ -2073,9 +2073,15 @@ static const struct drm_edid *mtk_dp_edid_read(struct drm_bridge *bridge,
>>>>>     		 */
>>>>>     		const struct edid *edid = drm_edid_raw(drm_edid);
>>>>>     		struct cea_sad *sads;
>>>>> +		int ret;
>>>>>     
>>>>> -		audio_caps->sad_count = drm_edid_to_sad(edid, &sads);
>>>>> -		kfree(sads);
>>>>> +		ret = drm_edid_to_sad(edid, &sads);
>>>>> +		/* Ignore any errors */
>>>>> +		if (ret < 0)
>>>>> +			ret = 0;
>>>>> +		if (ret)
>>>>
>>>> Eh, this will never work, because you're clearing the error before checking
>>>> if there's any error here?!?! :-P
>>>
>>> Don't get what you mean? Yes, I'm ignoring the error. Thus, in case
>>> of an error ret will be zero and there will be no free. If ret was
>>> zero, there won't be a free either. So you're left with the "normal"
>>> case, where you have to free the sads. Just like before.
>>>
>>>> Anyway in reality, it returns -ENOMEM if the allocation was not successful...
>>>> in the event that any future update adds any other error we'd be back with the same
>>>> issue, but I'm not sure how much should we worry about that.
>>>>
>>>> To be extremely safe, we could do...
>>>>
>>>> if (ret != -ENOMEM)
>>>> 	kfree(sads)
>>>>
>>>> audio_caps->sad_count = ret < 0 ? 0 : ret;
>>>
>>> Which is the same as above, but you only check for ENOMEM?
>>>
>>
>> Yes, the point is to avoid kfree(sads) for -ENOMEM only, as other errors that may
>> be introduced later might still allocate it and leave it allocated.
> 
> Honestly, I doubt that any sane function will allocate memory, then
> return an error and expect the caller to free it.
> 

My point was "you never know". But that wasn't a strong opinion anyway.

It's ok for me regardless of what you choose, either follow what I said or don't,
the end result is the same, you're still fixing the issue and both ways are
acceptable, so...

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>