From: sashiko-bot@kernel.org
To: "Nareshkumar Gollakoti" <naresh.kumar.g@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v4 2/7] drm/xe/devcoredump: Add GuC register snapshot to devcoredump
Date: Mon, 12 Oct 2026 15:03:58 +0000 [thread overview]
Message-ID: <sashiko-outbox-168310@kernel.org> (raw)
In-Reply-To: <20261012145237.3788198-3-naresh.kumar.g@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] xe: NULL pointer dereference of `q` in devcoredump_snapshot()
--
commit e0032c5e9ffbf65f21b038440b113313907d9c4c
Author: Nareshkumar Gollakoti <naresh.kumar.g@intel.com>
Subject: drm/xe/devcoredump: Add GuC register snapshot to devcoredump
This commit adds support for capturing GuC register state as part of the xe
devcoredump snapshot. It defines a dedicated GuC register snapshot structure
and records selected GT and media GuC status/error registers.
> diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c b/drivers/gpu/drm/xe/xe_devcoredump.c
> index 1dbee725f55a1..f4a22e46eda78 100644
> --- a/drivers/gpu/drm/xe/xe_devcoredump.c
> +++ b/drivers/gpu/drm/xe/xe_devcoredump.c
[ ... ]
> @@ -561,6 +591,14 @@ static void devcoredump_snapshot(struct xe_devcoredump *coredump,
> other_gt,
> XE_DBG_REGSET_RPM,
> XE_GT_TYPE_MEDIA);
> + ss->gt_guc_reg = xe_dbg_gt_snapshot_capture(q->gt,
> + other_gt,
> + XE_DBG_REGSET_GUC,
> + XE_GT_TYPE_MAIN);
[Severity: High]
Can this cause a NULL pointer dereference when devcoredump_snapshot() is
called?
The xe_devcoredump_gt() function explicitly passes NULL for the q (exec queue)
parameter in cases like TLB invalidation timeouts, where the hang is not tied
to a specific queue.
If q is NULL, the unconditional access to q->gt here will trigger a kernel
panic during the error handling path, crashing the system and preventing the
devcoredump from successfully completing.
Would it be safer to use the provided gt argument instead of q->gt?
> + ss->media_gt_guc_reg = xe_dbg_gt_snapshot_capture(q->gt,
> + other_gt,
> + XE_DBG_REGSET_GUC,
> + XE_GT_TYPE_MEDIA);
[Severity: High]
Similarly, does this unconditional access to q->gt risk a NULL pointer
dereference under the same conditions described above?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261012145237.3788198-1-naresh.kumar.g@intel.com?part=2
next prev parent reply other threads:[~2026-10-12 15:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 14:52 [PATCH v4 0/7] drm/xe: Capture additional HW register state in devcoredump Nareshkumar Gollakoti
2026-10-12 14:52 ` [PATCH v4 1/7] drm/xe/devcoredump: Capture GT fuse registers " Nareshkumar Gollakoti
2026-10-12 15:02 ` sashiko-bot
2026-10-12 14:52 ` [PATCH v4 2/7] drm/xe/devcoredump: Add GuC register snapshot to devcoredump Nareshkumar Gollakoti
2026-10-12 15:03 ` sashiko-bot [this message]
2026-10-12 14:52 ` [PATCH v4 3/7] drm/xe/guc: Print register addresses in capture snapshot output Nareshkumar Gollakoti
2026-10-12 14:52 ` [PATCH v4 4/7] drm/xe: dump GAM page fault report registers in devcoredump Nareshkumar Gollakoti
2026-10-12 15:02 ` sashiko-bot
2026-10-12 14:52 ` [PATCH v4 5/7] drm/xe/guc: add TDL, SLICE gfx registers to capture list Nareshkumar Gollakoti
2026-10-12 14:52 ` [PATCH v4 6/7] drm/xe: capture L3 node status registers in devcoredump Nareshkumar Gollakoti
2026-10-12 15:06 ` sashiko-bot
2026-10-12 14:52 ` [PATCH v4 7/7] drm/xe/guc: capture additional engine state registers Nareshkumar Gollakoti
2026-10-12 15:07 ` sashiko-bot
2026-10-12 18:56 ` ✗ CI.checkpatch: warning for drm/xe: Capture additional HW register state in devcoredump (rev4) Patchwork
2026-10-12 18:58 ` ✓ CI.KUnit: success " Patchwork
2026-10-12 22:04 ` ✓ Xe.CI.BAT: " Patchwork
2026-10-13 4:36 ` ✓ Xe.CI.FULL: " 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=sashiko-outbox-168310@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=naresh.kumar.g@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.