Re: [PATCH v9 1/7] drm/xe/gt: Use GT ordered workqueue for wedging

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/xe: gt_wedge_worker memory access assertion fails when device is suspended
--

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

drm/xe/gt: Use GT ordered workqueue for wedging

This commit introduces a GT ordered workqueue for wedging to avoid tearing
down exec queues synchronously and disrupting the scheduler while jobs are
in-flight. It also uses the for_each_initialized_gt() macro to help avoid
races if the device is declared wedged in the probe sequence.

> diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c
> index bc9bf6f0b5a79..27f32627a1f9b 100644
> --- a/drivers/gpu/drm/xe/xe_gt.c
> +++ b/drivers/gpu/drm/xe/xe_gt.c
[ ... ]
> @@ -1204,6 +1209,15 @@ struct xe_hw_engine *xe_gt_any_hw_engine(struct xe_gt *gt)
>  	return NULL;
>  }
>  
> +static void gt_wedge_worker(struct work_struct *w)
> +{
> +	struct xe_gt *gt = container_of(w, typeof(*gt), wedge.worker);
> +
> +	xe_device_assert_mem_access(gt_to_xe(gt));

[Severity: High]
Does this assertion safely hold in all contexts? The changelog mentions that
v9 drops the runtime PM guard because callers already hold a reference.
However, looking at the async callers that eventually invoke this worker,
they don't seem to actively hold a runtime PM reference that guarantees the
device is awake.

For example, when an AMC alert is handled:

drivers/gpu/drm/xe/xe_amc.c:xe_amc_work() {
    ...
    case AMC_ALERT_CATERR:
        dev_warn(amc->i2c->drm_dev, "AMC Alert: %s\n",
                 amc_alert[alert_reason]);
        xe_device_declare_wedged(i2c_client_to_xe_device(client));
        break;
    ...
}

Inside xe_device_declare_wedged(), the code uses xe_pm_runtime_get_noresume()
and then loops over GTs to call xe_gt_declare_wedged(), which queues this
worker. Since xe_pm_runtime_get_noresume() does not wake up a suspended
device, couldn't this result in gt_wedge_worker() executing while the device
is suspended, failing the xe_device_assert_mem_access() assertion and crashing
the kernel?

A similar pattern appears in
drivers/gpu/drm/xe/xe_pci_error.c:prepare_device_for_reset(), which also uses
xe_pm_runtime_get_noresume() before invoking the wedge path.

> +	xe_uc_declare_wedged(&gt->uc);
> +	xe_tlb_inval_reset(&gt->tlb_inval);
> +}
> +

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