From: sashiko-bot@kernel.org
To: "Mallesh Koujalagi" <mallesh.koujalagi@intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v13 1/4] drm: Add DRM_WEDGE_RECOVERY_COLD_RESET recovery method
Date: Wed, 05 Aug 2026 07:19:43 +0000 [thread overview]
Message-ID: <20260805071943.C84E81F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260805071152.1225416-7-mallesh.koujalagi@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The `event_string` buffer used for wedged uevents is limited to 32 bytes (`WEDGE_STR_LEN`), which is insufficient to hold multiple combined recovery methods. This leads to silent string truncation and a malformed UAPI payload.
--
--- Patch [1]: [PATCH v13 1/4] drm: Add DRM_WEDGE_RECOVERY_COLD_RESET recovery method ---
commit 091feacf4c7aa58c5985f7e23f67de90d3d5760f
Author: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
drm: Add DRM_WEDGE_RECOVERY_COLD_RESET recovery method
Introduce DRM_WEDGE_RECOVERY_COLD_RESET (BIT(4)) recovery method to handle
scenarios requiring device power cycle. This method addresses cases where
other recovery mechanisms are insufficient to restore device functionality.
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index e51ed959da89f..8519e97ef5d31 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -545,6 +545,8 @@ static const char *drm_get_wedge_recovery(unsigned int opt)
> return "bus-reset";
> case DRM_WEDGE_RECOVERY_VENDOR:
> return "vendor-specific";
> + case DRM_WEDGE_RECOVERY_COLD_RESET:
> + return "cold-reset";
[Severity: High]
This is a pre-existing issue, but will adding the "cold-reset" recovery
method cause the event_string buffer to overflow and silently truncate?
Looking at drm_dev_wedged_event() in drivers/gpu/drm/drm_drv.c, the
event_string buffer is limited to 32 bytes (WEDGE_STR_LEN). If multiple
recovery methods are combined, their appended strings can exceed this limit:
drivers/gpu/drm/drm_drv.c:drm_dev_wedged_event() {
char event_string[WEDGE_STR_LEN]; ...
...
len = scnprintf(event_string, sizeof(event_string), "%s", "WEDGED=");
for_each_set_bit(opt, &method, BITS_PER_TYPE(method)) {
recovery = drm_get_wedge_recovery(opt);
...
len += scnprintf(event_string + len,
sizeof(event_string) - len, "%s,", recovery);
}
if (recovery)
/* Get rid of trailing comma */
event_string[len - 1] = '\0';
...
}
When the string is truncated by scnprintf() to fit the 32-byte buffer, could
the trailing comma removal blindly overwrite the last character of the
truncated word (e.g. chopping "cold-reset" down to "cold-r")? It appears this
might result in a malformed UAPI payload being sent to userspace when
multiple recovery methods are combined.
> default:
> return NULL;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260805071152.1225416-6-mallesh.koujalagi@intel.com?part=1
next prev parent reply other threads:[~2026-08-05 7:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 7:11 [PATCH v13 0/4] Introduce cold reset recovery method Mallesh Koujalagi
2026-08-05 7:11 ` [PATCH v13 1/4] drm: Add DRM_WEDGE_RECOVERY_COLD_RESET " Mallesh Koujalagi
2026-08-05 7:19 ` sashiko-bot [this message]
2026-08-05 7:11 ` [PATCH v13 2/4] drm/doc: Document " Mallesh Koujalagi
2026-08-05 7:20 ` sashiko-bot
2026-08-05 7:11 ` [PATCH v13 3/4] drm/xe: Handle PUNIT errors by requesting cold-reset recovery Mallesh Koujalagi
2026-08-05 7:30 ` sashiko-bot
2026-08-05 7:11 ` [PATCH v13 4/4] drm/xe/ras: Use fault-inject to trigger cold-reset wedge Mallesh Koujalagi
2026-08-05 7:24 ` sashiko-bot
2026-08-05 9:13 ` Raag Jadav
2026-08-05 10:01 ` Mallesh, Koujalagi
2026-08-05 11:50 ` ✓ CI.KUnit: success for Introduce cold reset recovery method (rev13) Patchwork
2026-08-05 12:31 ` ✗ Xe.CI.BAT: failure " Patchwork
2026-08-05 22:59 ` ✗ Xe.CI.FULL: " Patchwork
2026-08-06 16:41 ` ✓ CI.KUnit: success for Introduce cold reset recovery method (rev14) Patchwork
2026-08-06 17:22 ` ✓ Xe.CI.BAT: " Patchwork
2026-08-07 5:53 ` ✗ Xe.CI.FULL: failure " Patchwork
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=20260805071943.C84E81F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=mallesh.koujalagi@intel.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.