ARM Sunxi Platform Development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Nicolas Frattaroli" <nicolas.frattaroli@collabora.com>
Cc: dri-devel@lists.freedesktop.org, linux-sunxi@lists.linux.dev
Subject: Re: [PATCH v7 5/5] drm/display: hdmi-state-helper: Init SCDC debugfs for HDMI
Date: Tue, 21 Jul 2026 09:11:56 +0000	[thread overview]
Message-ID: <20260721091157.4A4A91F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260721-scdc-link-health-v7-5-92df1b6ad5fc@collabora.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Reading the `scdc_status` debugfs file causes a kernel panic if the HDMI connector lacks an I2C DDC adapter (`connector->ddc == NULL`).
- [Medium] Concurrent reads of the `scdc_status` debugfs file cause a data race on the shared per-connector `priv->state` buffer.
- [Low] SCDC debugfs initialization is incorrectly skipped if the creation of the `infoframes` debugfs directory fails.
--

--- Patch [5]: [PATCH v7 5/5] drm/display: hdmi-state-helper: Init SCDC debugfs for HDMI ---
commit 4d2f5fcf6dba954346bc26d1af8d8e70d0cf5de0
Author: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

drm/display: hdmi-state-helper: Init SCDC debugfs for HDMI

Initialise the SCDC debugfs file for connectors that call the HDMI state
helper's debugfs_init helper. This makes all connectors that use the
helper expose the scdc_status file in their connector debugfs.

> diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> index 8d5ee10ceb874..709524b40c26f 100644
> --- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> +++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
[ ... ]
> @@ -1116,6 +1117,7 @@ void drm_hdmi_connector_debugfs_init(struct drm_connector *connector,
>  		return;

[Severity: Low]
Is it intended that drm_scdc_debugfs_init() is skipped if the infoframes
directory creation fails?

Right above this line, the code checks:

	dir = debugfs_create_dir("infoframes", root);
	if (IS_ERR(dir))
		return;

If debugfs_create_dir() fails, the early return skips the independent
drm_scdc_debugfs_init() call entirely.

>  
>  	create_hdmi_infoframe_files(connector, dir);
> +	drm_scdc_debugfs_init(connector, root);
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: High]
Does exposing this to all HDMI connectors cause a regression with a NULL
pointer dereference?

If an HDMI connector lacks an I2C adapter (connector->ddc is NULL) but
indicates SCDC support, reading the newly exposed scdc_status debugfs
file leads to a panic:

drivers/gpu/drm/display/drm_scdc_helper.c:scdc_status_show() {
	if (scdc->supported) {
		ret = drm_scdc_read_state(connector, st);
...
}

drivers/gpu/drm/display/drm_scdc_helper.c:drm_scdc_read_state() {
	ddc = connector->ddc;
	if (!scdc->supported)
		return -EOPNOTSUPP;
	/* Read in 128-byte chunks, to work around DP<->HDMI converters with issues. */
	ret = drm_scdc_read(ddc, 0, buf, 128);
...
}

drm_scdc_read() unconditionally passes the NULL pointer to i2c_transfer(),
causing a panic.

[Severity: Medium]
Could concurrent reads of the scdc_status debugfs file cause a regression
due to a data race?

drm_scdc_debugfs_init() allocates a single, shared struct scdc_debugfs_priv
per connector:

drivers/gpu/drm/display/drm_scdc_helper.c:drm_scdc_debugfs_init() {
	priv = drmm_kzalloc(connector->dev, sizeof(*priv), GFP_KERNEL);
...
}

When multiple processes concurrently read the debugfs file, they extract this
shared pointer:

drivers/gpu/drm/display/drm_scdc_helper.c:scdc_status_show() {
	struct scdc_debugfs_priv *priv = m->private;
	struct drm_scdc_state *st = &priv->state;
...
}

Since there is no locking across the sequential I2C reads and data parsing
in drm_scdc_read_state(), concurrent threads could overwrite priv->state
simultaneously.

>  }
>  EXPORT_SYMBOL(drm_hdmi_connector_debugfs_init);

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

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

Thread overview: 17+ 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
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-22  7:48   ` Dmitry Baryshkov
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 [this message]
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=20260721091157.4A4A91F000E9@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox