All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Nicolas Frattaroli" <nicolas.frattaroli@collabora.com>
Cc: linux-sunxi@lists.linux.dev, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v7 2/5] drm/scdc-helper: Add scdc_status debugfs entry
Date: Tue, 21 Jul 2026 09:10:11 +0000	[thread overview]
Message-ID: <20260721091011.B387A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260721-scdc-link-health-v7-2-92df1b6ad5fc@collabora.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Shared `scdc_debugfs_priv` state causes a data race on concurrent debugfs reads and leaks memory for dynamic connectors.
- [Medium] Connector `status` and `display_info` fields are accessed without holding the required DRM mode config mutex.
--

--- Patch [2]: [PATCH v7 2/5] drm/scdc-helper: Add scdc_status debugfs entry ---
commit 16b712ae50ae43d528857efe5b800f5abdef139f
Author: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

drm/scdc-helper: Add scdc_status debugfs entry

This commit adds a debugfs entry under the DRM connector to expose SCDC link
status information.

> diff --git a/drivers/gpu/drm/display/drm_scdc_helper.c b/drivers/gpu/drm/display/drm_scdc_helper.c
> index 8403f2390ab6a..5871fc101815d 100644
> --- a/drivers/gpu/drm/display/drm_scdc_helper.c
> +++ b/drivers/gpu/drm/display/drm_scdc_helper.c
[ ... ]
> @@ -276,3 +284,179 @@ bool drm_scdc_set_high_tmds_clock_ratio(struct drm_connector *connector,
[ ... ]
> +static int scdc_status_show(struct seq_file *m, void *data)
> +{
> +	struct scdc_debugfs_priv *priv = m->private;
> +	struct drm_scdc_state *st = &priv->state;
> +	struct drm_connector *connector = priv->connector;
> +	struct drm_scdc *scdc = &connector->display_info.hdmi.scdc;
> +	int i, ret;
> +
> +	drm_connector_get(connector);
> +
> +	if (connector->status != connector_status_connected) {

[Severity: Medium]
Are we missing a lock here? Reading connector->status and 
connector->display_info (such as scdc->supported below) without holding the 
required drm_mode_config.mutex might race with concurrent modeset or hotplug 
events, potentially leading to torn reads or an inconsistent state.

> +		ret = -ENODEV;
> +		goto err_conn_put;
> +	}
> +
> +	if (scdc->supported) {
> +		ret = drm_scdc_read_state(connector, st);

[Severity: High]
Can this cause a data race? Multiple processes reading this debugfs file
concurrently will simultaneously mutate the shared priv->state buffer inside 
drm_scdc_read_state(), leading to corrupted state data being displayed.

> +		if (ret)
> +			goto err_conn_put;
> +
> +		for (i = 0; i < ARRAY_SIZE(st->scdc); i += 16)
> +			seq_printf(m, "%*ph\n", 16, &st->scdc[i]);
> +
> +		seq_puts(m, "\n----------------\n\n");
> +	}
[ ... ]
> +void drm_scdc_debugfs_init(struct drm_connector *connector, struct dentry *root)
> +{
> +	struct scdc_debugfs_priv *priv;
> +
> +	if (!root || !connector)
> +		return;
> +
> +	priv = drmm_kzalloc(connector->dev, sizeof(*priv), GFP_KERNEL);

[Severity: High]
Does this leak memory on hot-unplug? Allocating the priv structure using 
drmm_kzalloc() ties its lifetime to the DRM device rather than the connector. 
For dynamic hotpluggable connectors (like DP MST), this memory might not be 
freed when the connector is destroyed.

> +	if (!priv)
> +		return;
> +
> +	priv->connector = connector;
> +
> +	debugfs_create_file("scdc_status", 0444, root, priv, &scdc_status_fops);
> +}
> +EXPORT_SYMBOL(drm_scdc_debugfs_init);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721-scdc-link-health-v7-0-92df1b6ad5fc@collabora.com?part=2

  reply	other threads:[~2026-07-21  9:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-21  8:58 [PATCH v7 0/5] Add SCDC information to connector debugfs Nicolas Frattaroli
2026-07-21  8:58 ` [PATCH v7 1/5] drm/scdc-helper: Don't use ssize_t return type for scdc_read/write Nicolas Frattaroli
2026-07-21  8:58 ` [PATCH v7 2/5] drm/scdc-helper: Add scdc_status debugfs entry Nicolas Frattaroli
2026-07-21  9:10   ` sashiko-bot [this message]
2026-07-21 12:41   ` Maxime Ripard
2026-07-21 13:01     ` Nicolas Frattaroli
2026-07-21 13:20       ` Maxime Ripard
2026-07-21  8:58 ` [PATCH v7 3/5] drm/scdc-helper: Implement parsing and printing HDMI 2.1 fields Nicolas Frattaroli
2026-07-21  9:10   ` sashiko-bot
2026-07-21 13:27     ` Nicolas Frattaroli
2026-07-21 12:42   ` Maxime Ripard
2026-07-21  8:59 ` [PATCH v7 4/5] drm/debugfs: Move HDMI debugfs registration to state helper Nicolas Frattaroli
2026-07-21 14:19   ` Maxime Ripard
2026-07-21  8:59 ` [PATCH v7 5/5] drm/display: hdmi-state-helper: Init SCDC debugfs for HDMI Nicolas Frattaroli
2026-07-21  9:11   ` sashiko-bot
2026-07-21 13:49   ` Maxime Ripard

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=20260721091011.B387A1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=nicolas.frattaroli@collabora.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.