linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Michael Walle" <mwalle@kernel.org>
To: "AngeloGioacchino Del Regno"
	<angelogioacchino.delregno@collabora.com>,
	"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>
Subject: Re: [PATCH] drm/mediatek/dp: fix spurious kfree()
Date: Fri, 17 May 2024 13:21:43 +0200	[thread overview]
Message-ID: <D1BVPABXTSPH.22ML1GLOMHEJR@kernel.org> (raw)
In-Reply-To: <0d8f89d4-e16e-4c8d-b983-38df8fcc387e@collabora.com>


[-- Attachment #1.1: Type: text/plain, Size: 2616 bytes --]

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.

-michael

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-05-17 11:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-17  9:30 [PATCH] drm/mediatek/dp: fix spurious kfree() Michael Walle
2024-05-17 10:35 ` AngeloGioacchino Del Regno
2024-05-17 11:07   ` Michael Walle
2024-05-17 11:09     ` AngeloGioacchino Del Regno
2024-05-17 11:21       ` Michael Walle [this message]
2024-05-17 11:23         ` AngeloGioacchino Del Regno
2024-05-17 13:12 ` Jani Nikula

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=D1BVPABXTSPH.22ML1GLOMHEJR@kernel.org \
    --to=mwalle@kernel.org \
    --cc=airlied@gmail.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=chunkuang.hu@kernel.org \
    --cc=daniel@ffwll.ch \
    --cc=jani.nikula@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=p.zabel@pengutronix.de \
    --cc=wenst@chromium.org \
    /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;
as well as URLs for NNTP newsgroup(s).