Re: [PATCH v9 5/7] drm/xe/pci_error: Flush GT wedge worker before bus reset

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] drm/xe: panic in prepare_device_for_reset() on uninitialized work_struct
- [Medium] drm/xe: assertion failures in wedge path on PCI error
--

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

drm/xe/pci_error: Flush GT wedge worker before bus reset

With GT wedging now done async, this commit makes sure the wedge worker
is flushed 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);

[Severity: Medium]
Will this trigger an assertion failure if a PCI error occurs when the device
is configured with wedged_mode=0?

If the user configures wedged_mode=0 (which resolves to XE_WEDGED_MODE_NEVER),
the device correctly skips GPU-hang wedging. However, when a PCI error forces
a bus reset, prepare_device_for_reset() unconditionally calls
xe_gt_declare_wedged() without checking the mode.

Looking at xe_gt_declare_wedged() and downstream functions like
xe_uc_declare_wedged() and xe_guc_declare_wedged(), they all contain assertions
checking wedged.mode:

void xe_gt_declare_wedged(struct xe_gt *gt)
{
	xe_gt_assert(gt, gt_to_xe(gt)->wedged.mode);
...

This will cause a cascade of kernel warnings if a PCI error is detected on a
device with wedged_mode=0.

> +		flush_work(&gt->wedge.worker);

[Severity: High]
Could this cause a panic by operating on a zero-initialized work_struct during
early probe?

If a hardware error (AER) is detected during device probe,
prepare_device_for_reset() can be called after xe_info_init() allocates the GT
structures but before xe_device_probe() calls xe_gt_init_early() to initialize
the wedge.worker.

Since for_each_gt() iterates over all allocated GTs rather than just the
initialized ones, flush_work() could be called on an uninitialized work_struct,
leading to a kernel oops or a WARN splat in __flush_work().

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

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