Re: [PATCH v10 8/9] drm/xe: Introduce xe_wedge

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] drm/xe: missing lock in xe_wedge_set_mode() allows inconsistent state
--

commit 099845d336cfe3f2b49209afcef197ab88c425f6
Author: Raag Jadav <raag.jadav@intel.com>
Subject: 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_wedge.c b/drivers/gpu/drm/xe/xe_wedge.c
> new file mode 100644
> index 0000000000000..2f35937c5e661
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_wedge.c

[ ... ]

> +int xe_wedge_set_mode(struct xe_device *xe, enum xe_wedged_mode mode)
> +{
> +	int ret;
> +
> +	ret = wedge_validate_mode(xe, mode);
> +	if (ret)
> +		return ret;
> +
> +	if (wedge_mode_needs_policy_update(xe, mode)) {
> +		ret = wedge_mode_set_reset_policy(xe, mode);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	xe->wedged.mode = mode;

[Severity: Low]
Can this sequence of updates lead to an inconsistent state if multiple threads
write to the wedged_mode debugfs node concurrently?

It looks like the multi-step update of the hardware reset policy and the
software mode tracking is not serialized by any lock in xe_wedge_set_mode().

If Thread A and Thread B concurrently write to the debugfs file:

Thread A checks wedge_mode_needs_policy_update() and proceeds to apply
the hardware settings.

Thread B checks and applies different settings.

Thread B writes its software state to xe->wedged.mode.

Thread A writes its software state to xe->wedged.mode.

Could the hardware reset policy become desynchronized from the software
state, potentially leading to lost hang recoveries or incorrect behavior?

> +
> +	return ret;
> +}

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