Re: [PATCH v10 9/9] drm/xe/ras: Move xe_ras_process_errors() to xe_ras

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] drm/xe: probe fails on boot-time RAS wedge instead of entering wedged state
- [High] xe: xe_gt_init() fails on early wedging aborting probe
- [Medium] drm/xe/ras: uevent lost when wedged before device_add()
--

commit e35d015152f1c4af5404ff382d3fce57a98e3c04
Author: Raag Jadav <raag.jadav@intel.com>
drm/xe/ras: Move xe_ras_process_errors() to xe_ras

This commit moves xe_ras_process_errors() back to xe_ras_init() during the
early probe sequence. This reverts a previous change to prevent PM reference
leaks in case of early wedging.

[ ... ]
> diff --git a/drivers/gpu/drm/xe/xe_ras.c b/drivers/gpu/drm/xe/xe_ras.c
> index 0072bb4cc5dfe..db3cbc186a514 100644
> --- a/drivers/gpu/drm/xe/xe_ras.c
> +++ b/drivers/gpu/drm/xe/xe_ras.c
> @@ -1212,6 +1212,13 @@ int xe_ras_init(struct xe_device *xe)
>  	get_offline_list(xe);
>  	get_offline_queue(xe);
>  
> +	/*
> +	 * During probe, process and log any errors detected by firmware while the driver was not
> +	 * loaded. Critical errors such as Punit and CSC are reported through Pcode init failure,
> +	 * causing the driver to enter survivability mode.
> +	 */
> +	xe_ras_process_errors(xe);
> +

[Severity: Medium]
Will this cause the wedge uevent to be lost?

Because xe_ras_init() executes early in the probe sequence, before
drm_dev_register() is called, declaring the device as wedged here will
schedule the wedge_work asynchronously. When the worker runs, it calls
drm_dev_wedged_event(), emitting a KOBJ_CHANGE uevent on the DRM kobject.

Since device_add() has not yet created the sysfs directory for the DRM
device, will userspace daemons silently drop this uevent?

[Severity: High]
Does wedging the device this early cause the driver probe to abort entirely
instead of entering survivability mode?

When xe_ras_process_errors() detects an error and wedges the device here, the
local GTs are skipped in xe_wedge_declare() because they are not yet
initialized. Later in xe_device_probe(), the driver will continue to GT
initialization:

xe_device_probe() {
    ...
    for_each_gt(gt, xe, id) {
        err = xe_gt_init(gt);
        if (err)
            return err;
    }
    ...
}

During this GT initialization, the driver will attempt to communicate with the
GuC hardware. For example, the call chain into GuC CT communication checks the
global wedged flag:

xe_guc_ct_send() / __guc_ct_send_locked() {
    if (xe_wedged(ct_to_xe(ct))) {
        ret = -ENOTRECOVERABLE;
        goto out;
    }
    ...
}

Since the device was globally marked as wedged by xe_ras_init(), this returns
an error that propagates up, causing xe_gt_init() and xe_device_probe() to
fail. Could this prevent the device from successfully binding and exposing
survivability mode to userspace?

>  	ret = devm_device_add_group(xe->drm.dev, &gpu_health_group);
>  	if (ret)
>  		xe_err(xe, "Failed to create GPU health sysfs, err=%d\n", ret);

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