Re: [PATCH v10 6/9] drm/xe/pci_error: Flush GT wedge worker before bus reset

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/xe: flush_work() in PCI error recovery triggers MMIO on suspended device
--

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

drm/xe/pci_error: Flush GT wedge worker before bus reset
    
This commit flushes the GT wedge worker synchronously to avoid side
effects during PCI bus reset.

> diff --git a/drivers/gpu/drm/xe/xe_pci_error.c b/drivers/gpu/drm/xe/xe_pci_error.c
> index e1b9dc5f0a6dc..a5c8fd67738cf 100644
> --- a/drivers/gpu/drm/xe/xe_pci_error.c
> +++ b/drivers/gpu/drm/xe/xe_pci_error.c
> @@ -30,8 +30,10 @@ static void prepare_device_for_reset(struct pci_dev *pdev)
>  
>  	xe_device_set_in_reset(xe);
>  
> -	for_each_gt(gt, xe, id)
> +	for_each_gt(gt, xe, id) {
>  		xe_gt_declare_wedged(gt);
> +		flush_work(&gt->wedge.worker);

[Severity: High]
Does flushing the wedge worker here trigger unauthorized MMIO accesses on
a suspended device?

If the device is runtime suspended (D3hot), prepare_device_for_reset()
takes a PM reference earlier in the function via xe_pm_runtime_get_noresume()
which does not wake up the device.

By synchronously flushing the wedge worker here, it executes in this suspended
context. The worker unconditionally calls xe_device_assert_mem_access() (which
fails because the device is suspended) and proceeds to perform MMIO accesses
such as xe_guc_softreset().

Accessing MMIO on a D3hot device can cause PCI master aborts, NMI system
crashes, or hardware hangs.

> +	}
>  
>  	pci_disable_device(pdev);
>  }

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