linux-kernel - Re: [PATCH 1/2] drm/connector: allow a .destroy callback for drmm-allocated connectors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250926165847.51f69473@booty>
Date: Fri, 26 Sep 2025 16:58:47 +0200
From: Luca Ceresoli <luca.ceresoli@...tlin.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard
 <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, David Airlie
 <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 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>, Hui Pu
 <Hui.Pu@...ealthcare.com>, Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
 dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] drm/connector: allow a .destroy callback for
 drmm-allocated connectors

Hi Dmitry,

On Fri, 26 Sep 2025 01:07:26 +0300
Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com> wrote:

> On Thu, Sep 25, 2025 at 07:19:49PM +0200, Luca Ceresoli wrote:
> > Some code is going to need connector-specific cleanup actions (namely
> > drm_bridge_connector will need to put refcounted bridges).
> > 
> > The .destroy callback is appropriate for this task but it is currently
> > forbidden by drmm_connector_init(). Relax this limitation and document it.
> > 
> > Signed-off-by: Luca Ceresoli <luca.ceresoli@...tlin.com>
> > 
> > ---
> > 
> > The other obvious approach would be adding a separate .cleanup callback for
> > the cleanup-only actions. I tried both, they both apparently work, so any
> > arguments and opinions on which approach is best within the overall DRM
> > design would be very useful here.  
> 
> Would it be better to use drmm-reset actions. I think the check here
> makes much more help overall than harm in your case, so I'd suggest
> leaving it in place.

Thanks for the feedback!

I think using drmm_add_action[_or_reset]() here makes sense indeed.

As I understand it, both .destroy and drmm_add_action[_or_reset]()
actions will trigger when the drm_device is removed. This is not ideal
for hotplugging because one would add/remove bridges while the
drm_device is persistent, so on multiple hot plug/unplug loops stale
resources would accumulate until the final card removal, perhaps at
system shutdown. However for now my goal is to have bridges refcount in
place to avoid use-after-free. Releasing resources for hot-unplugged
bridges for this case is a further step.

Bottom line: same drawback for both solutions, but the drmm action is
cleaner. v2 incoming with a drmm action.

Best regards,
Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com