Re: [PATCH v5 4/5] drm/xe: Introduce xe_wedge

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] workqueue: deadlock in xe_gt_wedge_declare via ordered_wq self-blocking
- [High] locking: flush_work() called from hardirq context in xe_mert_irq_handler
- [Low] build: incomplete enum xe_wedged_mode passed by value in header
--

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

drm/xe: Introduce xe_wedge

Consolidate wedging implementation into a dedicated xe_wedge component
for better maintainability. While at it, rename all wedge helpers
to match with component name.

> diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c
> index 775c826b68b42..ba10434763381 100644
> --- a/drivers/gpu/drm/xe/xe_gt.c
> +++ b/drivers/gpu/drm/xe/xe_gt.c
[ ... ]
> @@ -986,7 +993,7 @@ static void gt_reset_worker(struct work_struct *w)
>  
>  err_fail:
>  	xe_log_err_fatal(gt, GT, err, "reset failed\n");
> -	xe_device_declare_wedged(gt_to_xe(gt));
> +	xe_wedge_declare(gt_to_xe(gt), DRM_WEDGE_RECOVERY_REBIND | DRM_WEDGE_RECOVERY_BUS_RESET);

[Severity: High]
Can this sequence cause a deadlock? The gt_reset_worker is already executing
on the gt->ordered_wq workqueue. Calling xe_wedge_declare() eventually calls
xe_gt_wedge_declare() which queues gt->wedge.worker to the same ordered_wq
and then calls flush_work(). If the ordered workqueue has max_active=1, won't
it block permanently waiting for the newly queued item? A similar situation
exists in vf_post_migration_recovery().

>  err_pm_put:
>  	xe_pm_runtime_put(gt_to_xe(gt));
>  }
[ ... ]
> @@ -1190,16 +1205,16 @@ struct xe_hw_engine *xe_gt_any_hw_engine(struct xe_gt *gt)
>  }
>  
>  /**
> - * xe_gt_declare_wedged() - Declare GT wedged
> + * xe_gt_wedge_declare() - Declare GT wedged
>   * @gt: the GT object
>   *
>   * Wedge the GT which stops all submission, saves desired debug state, and
>   * cleans up anything which could timeout.
>   */
> -void xe_gt_declare_wedged(struct xe_gt *gt)
> +void xe_gt_wedge_declare(struct xe_gt *gt)
>  {
>  	xe_gt_assert(gt, gt_to_xe(gt)->wedged.mode);
>  
> -	xe_uc_declare_wedged(&gt->uc);
> -	xe_tlb_inval_reset(&gt->tlb_inval);
> +	queue_work(gt->ordered_wq, &gt->wedge.worker);
> +	flush_work(&gt->wedge.worker);

[Severity: High]
Does this flush_work() execute in hardirq context? The function
xe_mert_irq_handler() in xe_mert.c runs in hardirq context and calls
mert_handle_cat_error(), which calls xe_wedge_declare(), ultimately leading
here. Calling a sleeping function from atomic context will cause issues.

>  }
> diff --git a/drivers/gpu/drm/xe/xe_wedge.h b/drivers/gpu/drm/xe/xe_wedge.h
> new file mode 100644
> index 0000000000000..5fda8ce015d49
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_wedge.h
> @@ -0,0 +1,19 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2026 Intel Corporation
> + */
> +
> +#ifndef _XE_WEDGE_H_
> +#define _XE_WEDGE_H_
> +
> +#include <linux/types.h>
> +
> +struct xe_device;
> +enum xe_wedged_mode;
> +
> +bool xe_wedged(struct xe_device *xe);
> +void xe_wedge_declare(struct xe_device *xe, unsigned long method);
> +int xe_wedge_init(struct xe_device *xe);
> +int xe_wedge_set_mode(struct xe_device *xe, enum xe_wedged_mode mode);

[Severity: Low]
Is this prototype valid according to the C standard? The incomplete enum
xe_wedged_mode is being passed by value. Including xe_wedge_types.h directly
should resolve this build issue.

> +
> +#endif

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