From: sashiko-bot@kernel.org
To: "Badal Nilawar" <badal.nilawar@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v2 11/11] drm/xe/ras: Report correctable errors using SIGID
Date: Tue, 25 Aug 2026 18:03:04 +0000 [thread overview]
Message-ID: <20260825180304.C36D71F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260825175916.1103841-24-badal.nilawar@intel.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Passing raw `enum xe_ras_component` to `xe_log_from()` instead of a properly constructed `enum xe_log_component`, causing incorrect logging format and kernel warnings.
- [Medium] Unmapped `XE_RAS_COMP_RESERVED` causes `U32_MAX` to be passed as a default SIGID, breaking the stable signature ID tracking scheme by logging `SIGID=4294967295`.
--
commit 9b392e724340e7b28bbb985e627346fd4f036a93
Author: Badal Nilawar <badal.nilawar@intel.com>
drm/xe/ras: Report correctable errors using SIGID
This commit replaces the xe_warn() call for correctable errors with the
xe_log_from() helper to report them using SIGID format.
> diff --git a/drivers/gpu/drm/xe/xe_ras.c b/drivers/gpu/drm/xe/xe_ras.c
> index 4cd1d5eb75f4d..0becfadbb4cdf 100644
> --- a/drivers/gpu/drm/xe/xe_ras.c
> +++ b/drivers/gpu/drm/xe/xe_ras.c
> @@ -458,8 +458,11 @@ void xe_ras_counter_threshold_crossed(struct xe_device *xe,
> if (!ras_counter_is_valid(xe, &errors[id]))
> continue;
>
> - xe_warn(xe, "[RAS]: %s %s detected\n",
> - comp_to_str(component), sev_to_str(severity));
> + xe_log_from(xe, ras_sev_to_cper_sev(severity),
> + ras_comp_to_hw_sigid(component),
[Severity: Medium]
Will this leak U32_MAX as a SIGID to the logging infrastructure?
If ras_counter_is_valid() allows XE_RAS_COMP_RESERVED (3) to proceed,
ras_comp_to_hw_sigid() hits the default case and returns U32_MAX.
U32_MAX is then passed as the sigid to xe_log_from(), and __xe_log_emit()
blindly formats the sigid using %u, logging "SIGID=4294967295".
Does this break the stable, machine-matchable token format?
> + component,
[Severity: Medium]
Does this pass an invalid component type to xe_log_from()?
xe_log_from() expects its component parameter to be a constructed
enum xe_log_component (via MAKE_XE_LOG_COMPONENT), where the lower byte is
class and the upper byte is type.
Passing the raw enum xe_ras_component directly causes it to be misinterpreted
as CLASS=1 and TYPE=0. This triggers log_unknown_component_prefix() to be
invoked, printing a corrupted "DRIVER? " prefix and triggering a kernel WARN
on every RAS event if CONFIG_DRM_XE_DEBUG is enabled.
> + &errors[id], sizeof(errors[id]),
> + "error detected\n");
>
> /* Send event once per component */
> if (sent & BIT(component))
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260825175916.1103841-13-badal.nilawar@intel.com?part=11
next prev parent reply other threads:[~2026-08-25 18:03 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 17:59 [PATCH v2 00/11] Add CPER logging support for CRI Badal Nilawar
2026-08-25 17:59 ` [PATCH v2 01/11] drm/xe/xe_ras: Add support to retrieve info queue data " Badal Nilawar
2026-08-25 17:53 ` sashiko-bot
2026-08-26 0:54 ` Rodrigo Vivi
2026-08-25 20:48 ` Michal Wajdeczko
2026-08-25 17:59 ` [PATCH v2 02/11] drm/xe/xe_ras: Refactor get_counter() to return response structure Badal Nilawar
2026-08-25 17:59 ` [PATCH v2 03/11] drm/xe/cper: Add CPER structures and trace event Badal Nilawar
2026-08-25 17:51 ` sashiko-bot
2026-08-28 15:23 ` Rodrigo Vivi
2026-08-25 17:59 ` [PATCH v2 04/11] drm/xe/cper: APIs to prepare and log CPER record Badal Nilawar
2026-08-25 18:02 ` sashiko-bot
2026-08-26 0:59 ` Rodrigo Vivi
2026-08-25 17:59 ` [PATCH v2 05/11] drm/xe/cper: Prepare Intel CPER error info from info queue Badal Nilawar
2026-08-25 17:54 ` sashiko-bot
2026-08-25 17:59 ` [PATCH v2 06/11] drm/xe/cper: Log CPER records for aggregate counter retrival Badal Nilawar
2026-08-25 17:55 ` sashiko-bot
2026-08-26 1:01 ` Rodrigo Vivi
2026-08-25 17:59 ` [PATCH v2 07/11] drm/xe/cper: Allow hardware error CPER reporting from xe_log Badal Nilawar
2026-08-25 17:54 ` sashiko-bot
2026-08-27 21:27 ` Michal Wajdeczko
2026-08-25 17:59 ` [PATCH v2 08/11] drm/xe/ras: Report device memory errors using SIGID Badal Nilawar
2026-08-25 17:58 ` sashiko-bot
2026-08-27 20:25 ` Michal Wajdeczko
2026-08-25 17:59 ` [PATCH v2 09/11] drm/xe/ras: Report core compute " Badal Nilawar
2026-08-25 17:55 ` sashiko-bot
2026-08-25 17:59 ` [PATCH v2 10/11] drm/xe/ras: Report soc internal " Badal Nilawar
2026-08-28 15:20 ` Rodrigo Vivi
2026-08-25 17:59 ` [PATCH v2 11/11] drm/xe/ras: Report correctable " Badal Nilawar
2026-08-25 18:03 ` sashiko-bot [this message]
2026-08-25 18:29 ` ✗ CI.checkpatch: warning for Add CPER logging support for CRI (rev2) Patchwork
2026-08-25 18:31 ` ✓ CI.KUnit: success " Patchwork
2026-08-25 19:25 ` ✓ Xe.CI.BAT: " Patchwork
2026-08-25 22:06 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-08-26 19:50 ` [PATCH v2 00/11] Add CPER logging support for CRI Matt Roper
2026-08-27 20:12 ` Rodrigo Vivi
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=20260825180304.C36D71F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=badal.nilawar@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--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