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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] workqueue: self-deadlock in xe_gt_declare_wedged() when invoked from ordered_wq workers
- [High] xe: sleeping in atomic context via flush_work in xe_gt_declare_wedged
- [High] drm/xe: missing memory barriers when publishing gt->initialized allows workqueue corruption
--

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

drm/xe/gt: Use GT ordered workqueue for wedging
    
This commit introduces a worker for GT-specific wedge handling and queues it
on the GT ordered workqueue to prevent disrupting the scheduler while jobs are
in-flight. It also introduces the for_each_initialized_gt() macro to avoid
races during probe sequences.

> diff --git a/drivers/gpu/drm/xe/xe_device.h b/drivers/gpu/drm/xe/xe_device.h
> --- a/drivers/gpu/drm/xe/xe_device.h
> +++ b/drivers/gpu/drm/xe/xe_device.h
> @@ -139,6 +139,10 @@ static inline bool xe_device_uc_enabled(struct xe_device *xe)
>  	for_each_gt((gt__), (tile__)->xe, (id__)) \
>  		for_each_if((gt__)->tile == (tile__))
>  
> +#define for_each_initialized_gt(gt__, xe__, id__) \
> +	for_each_gt((gt__), (xe__), (id__)) \
> +		for_each_if(READ_ONCE((gt__)->initialized))

[Severity: High]
Does this missing acquire memory barrier allow workqueue corruption?

If a hardware error or AMC alert triggers device wedging on a different CPU
concurrently with xe_gt_init(), the for_each_initialized_gt() macro checks
this flag. However, READ_ONCE() does not emit memory barriers on all
architectures. 

On weakly-ordered CPUs (like ARM64), a concurrent reader's speculative loads
could be hoisted before the gt->initialized check completes, causing
xe_gt_declare_wedged() to invoke queue_work() on an uninitialized workqueue or
work struct.

Should this use smp_load_acquire() and smp_store_release() to guarantee
proper ordering?

> +
>  static inline struct xe_force_wake *gt_to_fw(struct xe_gt *gt)
>  {
>  	return &gt->pm.fw;

[ ... ]

> diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c
> --- a/drivers/gpu/drm/xe/xe_gt.c
> +++ b/drivers/gpu/drm/xe/xe_gt.c

[ ... ]

> @@ -769,6 +773,8 @@ int xe_gt_init(struct xe_gt *gt)
>  			return err;
>  	}
>  
> +	/* Must be last */
> +	WRITE_ONCE(gt->initialized, true);

[Severity: High]
Similar to the read side, WRITE_ONCE() lacks a release memory barrier. The
CPU could reorder this store before the INIT_WORK(&gt->wedge.worker) store
earlier in xe_gt_init(). Replacing this with smp_store_release() would
ensure the GT state initialization is visible before the flag is published.

>  	return 0;
>  }

[ ... ]

> @@ -1200,6 +1214,6 @@ void xe_gt_declare_wedged(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]
Can this flush_work() call create a self-deadlock?

If a worker thread already executing on gt->ordered_wq (such as
gt_reset_worker() upon a reset failure) invokes xe_device_declare_wedged(),
it will eventually call xe_gt_declare_wedged().

Since gt->ordered_wq has a concurrency level of 1, queue_work() will place
wedge.worker behind the currently executing worker. The executing worker
will then block in flush_work(), waiting for wedge.worker to complete,
resulting in an unresolvable circular dependency that hangs the workqueue.

[Severity: High]
Does this also introduce a sleeping in atomic context regression?

xe_device_declare_wedged() can be called from mert_handle_cat_error(), which
is executed by the xe_mert_irq_handler() in hardirq context (for example,
directly from dg1_irq_handler()).

The flush_work() function relies on might_sleep(). Calling a sleeping
function from an atomic hardirq context will cause a 'scheduling while
atomic' kernel panic.

>  }

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