[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZdRTx2lmHBVlcLub@hovoldconsulting.com>
Date: Tue, 20 Feb 2024 08:24:55 +0100
From: Johan Hovold <johan@...nel.org>
To: Markus Elfring <Markus.Elfring@....de>
Cc: Johan Hovold <johan+linaro@...nel.org>, freedreno@...ts.freedesktop.org,
dri-devel@...ts.freedesktop.org, linux-phy@...ts.infradead.org,
linux-arm-msm@...r.kernel.org, kernel-janitors@...r.kernel.org,
Andrzej Hajda <andrzej.hajda@...el.com>,
Bjorn Andersson <andersson@...nel.org>,
Daniel Vetter <daniel@...ll.ch>, David Airlie <airlied@...il.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Neil Armstrong <neil.armstrong@...aro.org>,
Robert Foss <rfoss@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>,
Vinod Koul <vkoul@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
Abhinav Kumar <quic_abhinavk@...cinc.com>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Jonas Karlman <jonas@...boo.se>,
Kishon Vijay Abraham I <kishon@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Kuogee Hsieh <quic_khsieh@...cinc.com>,
Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
Rob Clark <robdclark@...il.com>
Subject: Re: [PATCH 1/6] drm/bridge: aux-hpd: fix OF node leaks
On Mon, Feb 19, 2024 at 06:48:30PM +0100, Markus Elfring wrote:
> > The two device node references taken during allocation need to be
> > dropped when the auxiliary device is freed.
> …
> > +++ b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
> …
> > @@ -74,6 +75,8 @@ struct device *drm_dp_hpd_bridge_register(struct device *parent,
> >
> > ret = auxiliary_device_init(adev);
> > if (ret) {
> > + of_node_put(adev->dev.platform_data);
> > + of_node_put(adev->dev.of_node);
> > ida_free(&drm_aux_hpd_bridge_ida, adev->id);
> > kfree(adev);
> > return ERR_PTR(ret);
>
> The last two statements are also used in a previous if branch.
> https://elixir.bootlin.com/linux/v6.8-rc5/source/drivers/gpu/drm/bridge/aux-hpd-bridge.c#L63
>
> How do you think about to avoid such a bit of duplicate source code
> by adding a label here?
No, the current code is fine and what you are suggesting is in any case
unrelated to this fix.
If this function ever grows a third error path like that, I too would
consider it however.
Johan
Powered by blists - more mailing lists