From: sashiko-bot@kernel.org
To: "Raag Jadav" <raag.jadav@intel.com>, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v10 3/9] drm/xe/hw_error: Guard csc_hw_error_work() with runtime PM
Date: Fri, 16 Oct 2026 07:43:26 +0000 [thread overview]
Message-ID: <sashiko-outbox-173956@kernel.org> (raw)
In-Reply-To: <20261016072623.457392-4-raag.jadav@intel.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] xe: missing cancel_work_sync() for csc_hw_error_work causes UAF
- [Medium] drm/xe: missing multiple invocation protection in xe_survivability_mode_runtime_enable() causes sysfs WARN
- [Low] drm/xe: missing xe_pm.h header inclusion for guard(xe_pm_runtime)
--
commit 8e1fc55f44fb943c373142f62d0ab081c339411d
Author: Raag Jadav <raag.jadav@intel.com>
drm/xe/hw_error: Guard csc_hw_error_work() with runtime PM
This commit adds a runtime PM reference around the survivability mode
enablement path in the hardware error worker.
> diff --git a/drivers/gpu/drm/xe/xe_hw_error.c b/drivers/gpu/drm/xe/xe_hw_error.c
> index f53a6b3055de1..7575cc09cc2a9 100644
> --- a/drivers/gpu/drm/xe/xe_hw_error.c
> +++ b/drivers/gpu/drm/xe/xe_hw_error.c
> @@ -170,6 +170,7 @@ static void csc_hw_error_work(struct work_struct *work)
> struct xe_tile *tile = container_of(work, typeof(*tile), csc_hw_error_work);
> struct xe_device *xe = tile_to_xe(tile);
>
> + guard(xe_pm_runtime)(xe);
[Severity: Low]
Does this compile cleanly?
The guard(xe_pm_runtime) macro requires the corresponding cleanup class
definition class_xe_pm_runtime_t.
This class is defined in xe_pm.h, but it appears xe_hw_error.c doesn't
include it directly or indirectly, which might lead to an unknown type
build error.
[Severity: High]
Is there a missing work cancellation regression during device teardown?
csc_hw_error_work is queued to the system workqueue upon a hardware error.
If the driver is removed or the module unloaded, the DRM and device core
release paths will free the xe and tile structures.
If cancel_work_sync() is missing during teardown, couldn't an executing
or pending worker cause a use-after-free when it tries to dereference xe
in this guard?
> xe_survivability_mode_runtime_enable(xe);
[Severity: Medium]
Could multiple hardware errors trigger a sysfs warning regression here?
csc_hw_error_work() can be queued and executed multiple times. If
xe_survivability_mode_runtime_enable() is invoked unconditionally on each
run, it will attempt to re-register the existing sysfs files via
create_survivability_sysfs().
This could fail with -EEXIST and trigger a kernel warning about duplicate
filenames.
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261016072623.457392-1-raag.jadav@intel.com?part=3
next prev parent reply other threads:[~2026-10-16 7:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 7:25 [PATCH v10 0/9] Introduce xe_wedge Raag Jadav
2026-10-16 7:25 ` [PATCH v10 1/9] drm/xe/gt: Use GT ordered workqueue for wedging Raag Jadav
2026-10-16 7:50 ` sashiko-bot
2026-10-16 7:25 ` [PATCH v10 2/9] drm/xe: Drop xe_device_set_wedged_method() Raag Jadav
2026-10-16 7:25 ` [PATCH v10 3/9] drm/xe/hw_error: Guard csc_hw_error_work() with runtime PM Raag Jadav
2026-10-16 7:43 ` sashiko-bot [this message]
2026-10-16 7:25 ` [PATCH v10 4/9] drm/xe: Move xe_device_wedged_fini() registration to xe_device_probe_early() Raag Jadav
2026-10-16 7:25 ` [PATCH v10 5/9] drm/xe: Make xe_device_declare_wedged() IRQ safe Raag Jadav
2026-10-16 7:26 ` [PATCH v10 6/9] drm/xe/pci_error: Flush GT wedge worker before bus reset Raag Jadav
2026-10-16 7:44 ` sashiko-bot
2026-10-16 7:26 ` [PATCH v10 7/9] drm/xe/amc: Guard xe_amc_work() with runtime PM Raag Jadav
2026-10-16 7:36 ` sashiko-bot
2026-10-16 7:26 ` [PATCH v10 8/9] drm/xe: Introduce xe_wedge Raag Jadav
2026-10-16 7:34 ` sashiko-bot
2026-10-16 7:26 ` [PATCH v10 9/9] drm/xe/ras: Move xe_ras_process_errors() to xe_ras Raag Jadav
2026-10-16 7:52 ` sashiko-bot
2026-10-16 8:05 ` ✗ CI.checkpatch: warning for Introduce xe_wedge (rev9) Patchwork
2026-10-16 8:06 ` ✗ CI.KUnit: 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=sashiko-outbox-173956@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=raag.jadav@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.