Message-ID: <1d8908b1-b38e-4226-9433-cd9405c7ca63@nxp.com>
Date: Tue, 24 Jun 2025 10:44:03 +0800
From: Liu Ying <victor.liu@....com>
To: Luca Ceresoli <luca.ceresoli@...tlin.com>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 Andrzej Hajda <andrzej.hajda@...el.com>,
 Neil Armstrong <neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>,
 Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
 Jonas Karlman <jonas@...boo.se>, Jernej Skrabec <jernej.skrabec@...il.com>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Marek Vasut <marex@...x.de>, Stefan Agner <stefan@...er.ch>,
 Shawn Guo <shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>,
 Pengutronix Kernel Team <kernel@...gutronix.de>,
 Fabio Estevam <festevam@...il.com>, Hui Pu <Hui.Pu@...ealthcare.com>,
 Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
 dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
 imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v8 2/5] drm/bridge: get the bridge returned by
 drm_bridge_chain_get_first_bridge()

On 06/23/2025, Luca Ceresoli wrote:
> Hello Liu,

Luca,

> 
> On Mon, 23 Jun 2025 10:56:13 +0800
> Liu Ying <victor.liu@....com> wrote:
> 
>> On 06/21/2025, Luca Ceresoli wrote:
>>> drm_bridge_chain_get_first_bridge() returns a bridge pointer that the
>>> caller could hold for a long time. Increment the refcount of the returned
>>> bridge and document it must be put by the caller.  
>>
>> To make sure the incremented refcount is decremented once this patch is
>> applied, does it make sense to squash patch 3, 4 and 5 into this one?
> 
> I see there is a trade off here between bisectability and patch
> readability.
> 
> However about bisectability the problem is limited for this series. To
> get an actual get/put imbalance you'd have to be able to remove the
> bridge, but removing (part of) the bridge chain is not at all supported
> right now, and it won't be until after chapter 4 of this work (see
> cover letter).
> 
> However I realize there is an issue if:
> * patch 2 is applied but patches 3/4/5 are not
>   (it does not make sense to apply this series partially, but this
>   might happen when cherry-picking?)

Yes for cherry-picking and bisecting.

> * an entire DRM card is removed where
>   drm_bridge_chain_get_first_bridge() is used by some components
> 
> If both happen we'd have a get without put, thus a missing free and a
> memory leak for the container struct.

Yes, that's a memory leak.

> 
> Note that, besides drm_bridge_chain_get_first_bridge() that this
> series covers, there are various other accessors: see items 1.E.{2..8}

IIUC, without those items addressed, the issue we have is use-after-free,
but not the memory leak this patch introduces(without squash).

> in cover letter. For some of those there are many more changes to apply
> because they are called in more places. Squashing them would result in
> a really large patch that is likely hard to review and manage.

If the squash is done for each item separately and properly, I'd say
the memory leak issue can be avoided.  I assume patches for each item
would not be large.

> 
> So I'll leave the decision to DRM subsystem maintainers. For the time
> being I'm keeping the current approach given that Maxime already
> reviewed these patches in the past, not squashed.
> 
> Best regards,
> Luca
> 

-- 
Regards,
Liu Ying

Powered by blists - more mailing lists