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:07:06 +0200 [thread overview]
Message-ID: <D1BVE3G40OVL.3KX13LU75M122@kernel.org> (raw)
In-Reply-To: <de0191f3-271b-4f0e-aa73-910543587c9d@collabora.com>
[-- Attachment #1.1: Type: text/plain, Size: 2257 bytes --]
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?
-michael
>
> Cheers!
> Angelo
>
> > + kfree(sads);
> > + audio_caps->sad_count = ret;
> >
> > /*
> > * FIXME: This should use connector->display_info.has_audio from
[-- 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
next prev parent reply other threads:[~2024-05-17 11:07 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 [this message]
2024-05-17 11:09 ` AngeloGioacchino Del Regno
2024-05-17 11:21 ` Michael Walle
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=D1BVE3G40OVL.3KX13LU75M122@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).