| Message ID | 20260713-drm_refcount_wiring-v2-4-d3bb61f4bd4d@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-sunxi+bounces-24389-sunxi=pue.re@lists.linux.dev> X-Original-To: noreply@patchwork.local Delivered-To: noreply@patchwork.local Received: from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10]) by mxe881.netcup.net (Postfix) with ESMTPS id F0A5F1C2B71 for <noreply@patchwork.local>; Mon, 13 Jul 2026 13:56:26 +0200 (CEST) Authentication-Results: mxe881; dkim=pass header.d=redhat.com; spf=pass (sender IP is 172.234.253.10) smtp.mailfrom=linux-sunxi+bounces-24389-noreply=patchwork.local@lists.linux.dev smtp.helo=sea.lore.kernel.org Received-SPF: pass (mxe881: domain of lists.linux.dev designates 172.234.253.10 as permitted sender) client-ip=172.234.253.10; envelope-from=linux-sunxi+bounces-24389-noreply=patchwork.local@lists.linux.dev; helo=sea.lore.kernel.org; Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id 4427B3038F70 for <noreply@patchwork.local>; Mon, 13 Jul 2026 11:54:47 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 023C13EB7E5; Mon, 13 Jul 2026 11:54:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="eFVAomPo" X-Original-To: linux-sunxi@lists.linux.dev Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 72E913F484D for <linux-sunxi@lists.linux.dev>; Mon, 13 Jul 2026 11:54:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783943686; cv=none; b=TkWmyzBqXhWiTgCZrz4yzFZM11wRXh8wTHZFqAumSG/vMWH1/1toU6XwHteb92gdnqkAw+LKuJ0Hra4GbpWYr+YU3XRuh1eHsAbq9HqPzTp8RSxCA4pqIK7TlHkFR5wNwzQWKJ6pgkdWo6MwhKLUZaeN1rQq2ROUrlQJdKrlKco= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783943686; c=relaxed/simple; bh=sbVH6ShKanxtA5W9Xywae/baWgVvRmbdqq4dmgcH2zU=; h=From:Date:Subject:MIME-Version:Message-Id:References:In-Reply-To: To:Cc:Content-Type; b=W6mvIdTTxcCM3NhTX8Ujr4G00+HMeLWZ+J2oAi85ViBtzcbgYA6PZ0a6B9X6a6xV1KeUWKxZKm0cKQ1jelz/HldG5Au/WeuC6OKlBuVPLyusDRT4qtpABCuNDb2W6zix3RIPw0JRWL2WagBIcYVpPL+hkqddhZoTIeJk+pXoFSc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=eFVAomPo; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1783943684; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BjConvFAf3rvjYmbBQ7BQe1JT6YMn7Jt40JVrp+oOsg=; b=eFVAomPoc/n85k6EA0+TuGGP1DXlHJLWus86w/xGLrkuUktALWbvwoRZpZejEXvEik1oz3 jEF42q0GMGJVUJKRG2aRyfr9yDHXF9A6mECL3/IK93dDY8BjPAb6Wx5BTbbchji14l9vK2 FCZLnSIRdH74gC764Vl4SQ2RUOCAVOs= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-693-Zd5jyL0eOnCciocZgn6XnA-1; Mon, 13 Jul 2026 07:54:40 -0400 X-MC-Unique: Zd5jyL0eOnCciocZgn6XnA-1 X-Mimecast-MFC-AGG-ID: Zd5jyL0eOnCciocZgn6XnA_1783943675 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id E8AC61955E9E; Mon, 13 Jul 2026 11:54:34 +0000 (UTC) Received: from [192.168.1.153] (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B477C1800586; Mon, 13 Jul 2026 11:54:21 +0000 (UTC) From: Albert Esteve <aesteve@redhat.com> Date: Mon, 13 Jul 2026 13:53:07 +0200 Subject: [PATCH v2 4/5] drm/panel: find_panel_by_fwnode() return a counted reference Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: <linux-sunxi.lists.linux.dev> List-Subscribe: <mailto:linux-sunxi+subscribe@lists.linux.dev> List-Unsubscribe: <mailto:linux-sunxi+unsubscribe@lists.linux.dev> MIME-Version: 1.0 Message-Id: <20260713-drm_refcount_wiring-v2-4-d3bb61f4bd4d@redhat.com> References: <20260713-drm_refcount_wiring-v2-0-d3bb61f4bd4d@redhat.com> In-Reply-To: <20260713-drm_refcount_wiring-v2-0-d3bb61f4bd4d@redhat.com> To: Neil Armstrong <neil.armstrong@linaro.org>, Jessica Zhang <jesszhan0024@gmail.com>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>, David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>, Andrzej Hajda <andrzej.hajda@intel.com>, Robert Foss <rfoss@kernel.org>, Laurent Pinchart <Laurent.pinchart@ideasonboard.com>, Jonas Karlman <jonas@kwiboo.se>, Jernej Skrabec <jernej.skrabec@gmail.com>, Luca Ceresoli <luca.ceresoli@bootlin.com>, Inki Dae <inki.dae@samsung.com>, Jagan Teki <jagan@amarulasolutions.com>, Marek Szyprowski <m.szyprowski@samsung.com>, Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>, Lucas Stach <l.stach@pengutronix.de>, Frank Li <Frank.Li@nxp.com>, Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix Kernel Team <kernel@pengutronix.de>, Fabio Estevam <festevam@gmail.com>, Paul Cercueil <paul@crapouillou.net>, Linus Walleij <linusw@kernel.org>, Marek Vasut <marex@denx.de>, Stefan Agner <stefan@agner.ch>, Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>, Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>, Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>, Geert Uytterhoeven <geert+renesas@glider.be>, Magnus Damm <magnus.damm@gmail.com>, Biju Das <biju.das.jz@bp.renesas.com>, Sandy Huang <hjc@rock-chips.com>, =?utf-8?q?Heiko_St=C3=BCbner?= <heiko@sntech.de>, Andy Yan <andy.yan@rock-chips.com>, Yannick Fertre <yannick.fertre@foss.st.com>, Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>, Philippe Cornu <philippe.cornu@foss.st.com>, Maxime Coquelin <mcoquelin.stm32@gmail.com>, Alexandre Torgue <alexandre.torgue@foss.st.com>, Chen-Yu Tsai <wens@kernel.org>, Samuel Holland <samuel@sholland.org>, Jyri Sarha <jyri.sarha@iki.fi>, Jingoo Han <jingoohan1@gmail.com>, Seung-Woo Kim <sw0312.kim@samsung.com>, Kyungmin Park <kyungmin.park@samsung.com>, Krzysztof Kozlowski <krzk@kernel.org>, Peter Griffin <peter.griffin@linaro.org>, Alim Akhtar <alim.akhtar@samsung.com>, Alison Wang <alison.wang@nxp.com>, Paul Kocialkowski <paulk@sys-base.io>, Alain Volmat <alain.volmat@foss.st.com>, Raphael Gallais-Pou <rgallaispou@gmail.com>, Thierry Reding <thierry.reding@kernel.org>, Mikko Perttunen <mperttunen@nvidia.com>, Jonathan Hunter <jonathanh@nvidia.com> Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, linux-sunxi@lists.linux.dev, linux-samsung-soc@vger.kernel.org, linux-tegra@vger.kernel.org, Albert Esteve <aesteve@redhat.com> X-Developer-Signature: v=1; a=ed25519-sha256; t=1783943594; l=2316; i=aesteve@redhat.com; s=20260303; h=from:subject:message-id; bh=sbVH6ShKanxtA5W9Xywae/baWgVvRmbdqq4dmgcH2zU=; b=P+uXW64NeMeDz+v7ZdK9Rk/p7UzsOiF++6hDBewi6tGE7qdfB+UP54eECes9KOSS7cXXFhGxn N80BV1LxXkUCzr74V7G2Teaj6ix2xiKoAkyDXxCzT+PHAEdXFcA/Vq2 X-Developer-Key: i=aesteve@redhat.com; a=ed25519; pk=YSFz6sOHd2L45+Fr8DIvHTi6lSIjhLZ5T+rkxspJt1s= X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: sRogTds26Q-YK7qyQ_sUeFZoibzHGmQQ6MIXOHehsJQ_1783943675 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspamd-worker-8404 X-Spamd-Result: default: False [-2.16 / 15.00]; BAYES_HAM(-5.50)[100.00%]; RBL_SENDERSCORE(2.00)[172.234.253.10:from]; SUSPICIOUS_RECIPS(1.50)[]; MAILLIST(-0.15)[generic]; MIME_GOOD(-0.10)[text/plain]; BAD_REP_POLICIES(0.10)[]; HAS_LIST_UNSUB(-0.01)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[sea.lore.kernel.org:rdns,sea.lore.kernel.org:helo]; RCVD_COUNT_SEVEN(0.00)[7]; FROM_HAS_DN(0.00)[]; ARC_ALLOW(0.00)[subspace.kernel.org:s=arc-20240116:i=1]; TAGGED_RCPT(0.00)[renesas]; FUZZY_BLOCKED(0.00)[rspamd.com]; PRECEDENCE_BULK(0.00)[]; R_DKIM_ALLOW(0.00)[redhat.com:s=mimecast20190719]; FORGED_SENDER_MAILLIST(0.00)[]; FROM_NEQ_ENVFROM(0.00)[aesteve@redhat.com,linux-sunxi@lists.linux.dev]; TAGGED_FROM(0.00)[bounces-24389-noreply=patchwork.local]; DKIM_TRACE(0.00)[redhat.com:+]; DMARC_POLICY_ALLOW(0.00)[redhat.com,quarantine]; R_SPF_ALLOW(0.00)[+ip4:172.234.253.10]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[170.10.129.124:received,54.186.198.63:received,100.90.174.1:received]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:63949, ipnet:172.234.224.0/19, country:SG]; RCPT_COUNT_GT_50(0.00)[68]; FORGED_RECIPIENTS_MAILLIST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_TO(0.00)[linaro.org,gmail.com,linux.intel.com,kernel.org,suse.de,ffwll.ch,intel.com,ideasonboard.com,kwiboo.se,bootlin.com,samsung.com,amarulasolutions.com,oss.nxp.com,pengutronix.de,nxp.com,crapouillou.net,denx.de,agner.ch,glider.be,bp.renesas.com,rock-chips.com,sntech.de,foss.st.com,sholland.org,iki.fi,sys-base.io,nvidia.com]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[172.234.253.10:from] X-Rspamd-Queue-Id: F0A5F1C2B71 X-MORS-Enabled: yes X-MORS-DOMAIN: patchwork.local X-MORS-HOSTING: hosting172546 X-MORS-USER: hosting172546 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= |
| Series |
drm/panel: refcounting panel lookups and references
|
|
Commit Message
Albert Esteve
July 13, 2026, 11:53 a.m. UTC
find_panel_by_fwnode() is the fwnode-based counterpart to
of_drm_find_panel(), used internally by drm_panel_add_follower().
Like of_drm_find_panel(), it returned an unrefcounted pointer,
leaving a window where the panel could be freed between the lookup
and first use.
drm_panel_add_follower() worked around the missing panel kref by
calling get_device() on the panel's underlying struct device.
However, get_device() only prevents the device kobject from being freed.
It does not prevent the panel's kzalloc()'d container memory from being
released when the kref reaches zero.
Apply the same fix: call drm_panel_get() under panel_lock before
returning. Since find_panel_by_fwnode() now transfers a counted
reference to drm_panel_add_follower(), drm_panel_remove_follower()
must balance it with a matching drm_panel_put().
Signed-off-by: Albert Esteve <aesteve@redhat.com>
---
drivers/gpu/drm/drm_panel.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
Comments
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: New issues: - [Medium] Drivers calling of_drm_find_panel() directly leak the returned panel reference. Pre-existing issues: - [High] TOCTOU race in drm_panel_add_follower() when acquiring the panel's underlying device, leading to a potential Use-After-Free of panel->dev. -- --- Patch [4]: [PATCH v2 4/5] drm/panel: find_panel_by_fwnode() return a counted reference --- commit 5cd4c479944cf29f6f5aa4a3e31207bf48dc0567 Author: Albert Esteve <aesteve@redhat.com> drm/panel: find_panel_by_fwnode() return a counted reference This commit updates find_panel_by_fwnode() to return a refcounted pointer to the panel, mirroring a similar fix made to of_drm_find_panel(). It calls drm_panel_get() under the panel_lock before returning, ensuring the memory is not freed prematurely. Callers are now responsible for balancing this with drm_panel_put(), which is added to drm_panel_remove_follower(). > diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c > index 72cf86253c0cd..a00ae98ed0956 100644 > --- a/drivers/gpu/drm/drm_panel.c > +++ b/drivers/gpu/drm/drm_panel.c > @@ -542,7 +542,13 @@ int of_drm_get_panel_orientation(const struct device_node *np, > EXPORT_SYMBOL(of_drm_get_panel_orientation); > #endif > > -/* Find panel by fwnode. This should be identical to of_drm_find_panel(). */ > +/* > + * Find panel by fwnode, returning a counted reference. > + * > + * Behaves identically to of_drm_find_panel(). On success the returned > + * pointer has been passed through drm_panel_get(); the caller must call > + * drm_panel_put() when done with it. > + */ [Severity: Medium] Since the earlier patch in this series updated of_drm_find_panel() to also return a counted reference, do drivers that call it directly need to drop their reference to prevent a memory leak? For example, in bridge drivers like lvds-codec.c: drivers/gpu/drm/bridge/lvds-codec.c:lvds_codec_probe() { panel = of_drm_find_panel(panel_node); of_node_put(panel_node); ... lvds_codec->panel_bridge = devm_drm_panel_bridge_add_typed(dev, panel, lvds_codec->connector_type); } Because devm_drm_panel_bridge_add_typed() takes its own reference to the panel via drm_panel_get(), does this code leak the initial reference returned by of_drm_find_panel() since drm_panel_put() is never called? This same leak pattern appears to exist in other callers as well, such as samsung-dsim.c:samsung_dsim_host_attach() and rcar_du_encoder.c:rcar_du_encoder_init(). > static struct drm_panel *find_panel_by_fwnode(const struct fwnode_handle *fwnode) > { > struct drm_panel *panel; > @@ -554,6 +560,7 @@ static struct drm_panel *find_panel_by_fwnode(const struct fwnode_handle *fwnode > > list_for_each_entry(panel, &panel_list, list) { > if (dev_fwnode(panel->dev) == fwnode) { > + drm_panel_get(panel); > mutex_unlock(&panel_lock); [Severity: High] This is a pre-existing issue, but is there a time-of-check to time-of-use race condition when callers attempt to pin the underlying device? When find_panel_by_fwnode() (or find_panel_by_dev()) returns, the panel's internal refcount is incremented under panel_lock, but the underlying struct device (panel->dev) is not pinned. If a concurrent unbind occurs before the caller pins the device, the device memory could be freed. For example, looking at drm_panel_add_follower(): drivers/gpu/drm/drm_panel.c:drm_panel_add_follower() { panel = find_panel_by_dev(follower_dev); if (IS_ERR(panel)) return PTR_ERR(panel); get_device(panel->dev); } If the panel device driver unbinds immediately after panel_lock is dropped, could get_device(panel->dev) trigger a use-after-free on the destroyed device? > return panel; > } [ ... ]
On Mon, Jul 13, 2026 at 2:08 PM <sashiko-bot@kernel.org> wrote: > > Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: > > New issues: > - [Medium] Drivers calling of_drm_find_panel() directly leak the returned panel reference. > > Pre-existing issues: > - [High] TOCTOU race in drm_panel_add_follower() when acquiring the panel's underlying device, leading to a potential Use-After-Free of panel->dev. > -- > > --- Patch [4]: [PATCH v2 4/5] drm/panel: find_panel_by_fwnode() return a counted reference --- > commit 5cd4c479944cf29f6f5aa4a3e31207bf48dc0567 > Author: Albert Esteve <aesteve@redhat.com> > > drm/panel: find_panel_by_fwnode() return a counted reference > > This commit updates find_panel_by_fwnode() to return a refcounted pointer > to the panel, mirroring a similar fix made to of_drm_find_panel(). It calls > drm_panel_get() under the panel_lock before returning, ensuring the memory > is not freed prematurely. Callers are now responsible for balancing this > with drm_panel_put(), which is added to drm_panel_remove_follower(). > > > diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c > > index 72cf86253c0cd..a00ae98ed0956 100644 > > --- a/drivers/gpu/drm/drm_panel.c > > +++ b/drivers/gpu/drm/drm_panel.c > > @@ -542,7 +542,13 @@ int of_drm_get_panel_orientation(const struct device_node *np, > > EXPORT_SYMBOL(of_drm_get_panel_orientation); > > #endif > > > > -/* Find panel by fwnode. This should be identical to of_drm_find_panel(). */ > > +/* > > + * Find panel by fwnode, returning a counted reference. > > + * > > + * Behaves identically to of_drm_find_panel(). On success the returned > > + * pointer has been passed through drm_panel_get(); the caller must call > > + * drm_panel_put() when done with it. > > + */ > > [Severity: Medium] > Since the earlier patch in this series updated of_drm_find_panel() to > also return a counted reference, do drivers that call it directly need > to drop their reference to prevent a memory leak? > > For example, in bridge drivers like lvds-codec.c: > > drivers/gpu/drm/bridge/lvds-codec.c:lvds_codec_probe() { > panel = of_drm_find_panel(panel_node); > of_node_put(panel_node); > ... > lvds_codec->panel_bridge = devm_drm_panel_bridge_add_typed(dev, panel, > lvds_codec->connector_type); > } > > Because devm_drm_panel_bridge_add_typed() takes its own reference to the > panel via drm_panel_get(), does this code leak the initial reference > returned by of_drm_find_panel() since drm_panel_put() is never called? > > This same leak pattern appears to exist in other callers as well, such as > samsung-dsim.c:samsung_dsim_host_attach() and > rcar_du_encoder.c:rcar_du_encoder_init(). Uh this is a real issue that I missed in several callers. I will add drm_panel_put() after the bridge creation where needed in the next version. BR, Albert. > > > static struct drm_panel *find_panel_by_fwnode(const struct fwnode_handle *fwnode) > > { > > struct drm_panel *panel; > > @@ -554,6 +560,7 @@ static struct drm_panel *find_panel_by_fwnode(const struct fwnode_handle *fwnode > > > > list_for_each_entry(panel, &panel_list, list) { > > if (dev_fwnode(panel->dev) == fwnode) { > > + drm_panel_get(panel); > > mutex_unlock(&panel_lock); > > [Severity: High] > This is a pre-existing issue, but is there a time-of-check to time-of-use > race condition when callers attempt to pin the underlying device? > > When find_panel_by_fwnode() (or find_panel_by_dev()) returns, the panel's > internal refcount is incremented under panel_lock, but the underlying > struct device (panel->dev) is not pinned. > > If a concurrent unbind occurs before the caller pins the device, the device > memory could be freed. For example, looking at drm_panel_add_follower(): > > drivers/gpu/drm/drm_panel.c:drm_panel_add_follower() { > panel = find_panel_by_dev(follower_dev); > if (IS_ERR(panel)) > return PTR_ERR(panel); > > get_device(panel->dev); > } > > If the panel device driver unbinds immediately after panel_lock is dropped, > could get_device(panel->dev) trigger a use-after-free on the destroyed > device? > > > return panel; > > } > > [ ... ] > > -- > Sashiko AI review · https://sashiko.dev/#/patchset/20260713-drm_refcount_wiring-v2-0-d3bb61f4bd4d@redhat.com?part=4 >
On Mon, 13 Jul 2026 13:53:07 +0200, Albert Esteve wrote: > find_panel_by_fwnode() is the fwnode-based counterpart to > of_drm_find_panel(), used internally by drm_panel_add_follower(). > Like of_drm_find_panel(), it returned an unrefcounted pointer, > leaving a window where the panel could be freed between the lookup > and first use. > > [ ... ] Acked-by: Maxime Ripard <mripard@kernel.org> Thanks! Maxime
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c index 72cf86253c0cd..a00ae98ed0956 100644 --- a/drivers/gpu/drm/drm_panel.c +++ b/drivers/gpu/drm/drm_panel.c @@ -542,7 +542,13 @@ int of_drm_get_panel_orientation(const struct device_node *np, EXPORT_SYMBOL(of_drm_get_panel_orientation); #endif -/* Find panel by fwnode. This should be identical to of_drm_find_panel(). */ +/* + * Find panel by fwnode, returning a counted reference. + * + * Behaves identically to of_drm_find_panel(). On success the returned + * pointer has been passed through drm_panel_get(); the caller must call + * drm_panel_put() when done with it. + */ static struct drm_panel *find_panel_by_fwnode(const struct fwnode_handle *fwnode) { struct drm_panel *panel; @@ -554,6 +560,7 @@ static struct drm_panel *find_panel_by_fwnode(const struct fwnode_handle *fwnode list_for_each_entry(panel, &panel_list, list) { if (dev_fwnode(panel->dev) == fwnode) { + drm_panel_get(panel); mutex_unlock(&panel_lock); return panel; } @@ -690,6 +697,7 @@ void drm_panel_remove_follower(struct drm_panel_follower *follower) mutex_unlock(&panel->follower_lock); put_device(panel->dev); + drm_panel_put(panel); } EXPORT_SYMBOL(drm_panel_remove_follower);