Re: [PATCH v6 4/7] drm/xe: Make xe_device_declare_wedged() IRQ safe

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] pm: MMIO access on suspended device during async wedge
--

commit bce18d1215504bf5f21999a5ea9ee776aca1fe38
Author: Raag Jadav <raag.jadav@intel.com>

drm/xe: Make xe_device_declare_wedged() IRQ safe

This commit defers wedge handling to a dedicated worker, allowing
xe_device_declare_wedged() to be safely called from IRQ contexts such as
handling MERT CAT errors.

> diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
> --- a/drivers/gpu/drm/xe/xe_device.c
> +++ b/drivers/gpu/drm/xe/xe_device.c
> @@ -1405,29 +1421,28 @@ void xe_device_declare_wedged(struct xe_device *xe, unsigned long method)
>  
>  	if (!atomic_xchg(&xe->wedged.flag, 1)) {
>  		xe->needs_flr_on_fini = true;
> -		xe_pm_runtime_get_noresume(xe);
> +		pm_runtime_get_noresume(xe->drm.dev);

[Severity: High]
Does this allow MMIO access on a suspended device when a wedge is triggered
from an IRQ context?

If a hardware error (like a MERT CAT error) triggers an IRQ while the
device is in the RPM_SUSPENDED state, pm_runtime_get_noresume() will
increment the usage counter but will not wake the device up.

The GT wedge worker is then scheduled:

>  		xe_log_err_fatal(xe, WEDGED, -EIO, "Device declared wedged!\n");
>  		xe_err_once(xe, "IOCTLs and executions are now blocked!\n"
>  			    "For recovery procedure, refer to %s\n"
>  			    "Please file a _new_ bug report at %s\n",
>  			    WEDGED_URL, XE_BUG_URL);
> -	}
>  
> -	for_each_initialized_gt(gt, xe, id)
> -		xe_gt_declare_wedged(gt);
> +		for_each_initialized_gt(gt, xe, id)
> +			xe_gt_declare_wedged(gt);

And runs asynchronously without ensuring the device is resumed:

gt_wedge_worker()
  xe_uc_declare_wedged()
    xe_guc_declare_wedged()
      xe_guc_submit_wedge()
        xe_guc_softreset()
          xe_guc_mmio_send()

Since the device might still be suspended, this sequence can result in
xe_guc_mmio_send() performing MMIO accesses on powered-down hardware,
causing invalid register reads (e.g., returning 0xffffffff), hardware
timeouts, or PCIe bus errors.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261014055215.330408-1-raag.jadav@intel.com?part=4