Re: [PATCH 1/2] drm/xe/xe_pci_error: Wait for pcode init post SBR

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Data Race / Missing Mutual Exclusion in PCODE mailbox access during PCI error recovery
--

commit 6f04a64effec675eee1b5da08bc2d84a4196d4ed
Author: Riana Tauro <riana.tauro@intel.com>

drm/xe/xe_pci_error: Wait for pcode init post SBR

This commit adds a wait for Pcode initialization before accessing the
device post Secondary Bus Reset (SBR) in xe_pci_error_slot_reset().

> diff --git a/drivers/gpu/drm/xe/xe_pci_error.c b/drivers/gpu/drm/xe/xe_pci_error.c
> index 79ce0c671549a..3e9c77f8483d6 100644
> --- a/drivers/gpu/drm/xe/xe_pci_error.c
> +++ b/drivers/gpu/drm/xe/xe_pci_error.c
> @@ -109,6 +110,10 @@ static pci_ers_result_t xe_pci_error_slot_reset(struct pci_dev *pdev)
>  		return PCI_ERS_RESULT_DISCONNECT;
>  	}
>  
> +	err = xe_pcode_probe_early(xe);
> +	if (err)
> +		return PCI_ERS_RESULT_DISCONNECT;
> +

[Severity: High]
Does this code introduce a data race in PCODE mailbox access during PCI error
recovery?

xe_pcode_probe_early() calls xe_pcode_ready() without locking:

drivers/gpu/drm/xe/xe_pcode.c:xe_pcode_probe_early() {
	return xe_pcode_ready(xe, false);
}

The false argument explicitly disables tile->pcode.lock acquisition. However,
at this point in xe_pci_error_slot_reset(), the userspace interfaces like
hwmon sysfs are still registered and accessible.

If a userspace process reads hwmon sysfs limits (e.g., power1_max_interval)
while PCI error recovery is executing, the sysfs read will legitimately
acquire tile->pcode.lock and access PCODE. Meanwhile, this function will
bypass the lock and execute concurrent MMIO accesses to the same PCODE
registers.

Can this lead to hardware state machine corruption and the execution of
malformed commands by the PCODE microcontroller? Hwmon read handlers do not
check the wedged.flag, and sysfs interfaces are not removed until later
when pdev->driver->remove(pdev) is called.

>  	/*
>  	 * Secondary Bus Reset causes all VRAM state to be lost along with
>  	 * hardware state. As an initial step, re-probe the device to

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828113104.319843-4-riana.tauro@intel.com?part=1