Re: [PATCH 2/2] drm/i915/dmc_wl: Avoid blocking on delayed wakelock release

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm/i915/dmc_wl: race allows delayed work execution after disable
--

commit c0608498f162e6c645a132e26ca4016580c97dce
Author: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>

drm/i915/dmc_wl: Avoid blocking on delayed wakelock release

This commit modifies intel_dmc_wl_disable() to cancel the pending wakelock
release work rather than flushing it. This prevents the DC-exit path from
being unnecessarily delayed by workqueue scheduling and ACK polling. It drops
the work when disabling the wakelock instead of forcing it to run.

> diff --git a/drivers/gpu/drm/i915/display/intel_dmc_wl.c b/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> index ab4e0e9573dfb..3eae119009782 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc_wl.c
> @@ -400,7 +400,7 @@ void intel_dmc_wl_disable(struct intel_display *display)
>  	if (!__intel_dmc_wl_supported(display))
>  		return;
>  
> -	intel_dmc_wl_flush_release_work(display);
> +	cancel_delayed_work_sync(&wl->work);

[Severity: Medium]
Could this leave a stray delayed work queued after the wakelock is disabled?

Since cancel_delayed_work_sync() is called outside of wl->lock and before
wl->enabled is cleared, could a concurrent intel_dmc_wl_put() race here?

If CPU1 is in intel_dmc_wl_disable() just after cancel_delayed_work_sync(),
and CPU2 calls intel_dmc_wl_put():

CPU2 takes the lock in intel_dmc_wl_put(), sees wl->enabled is still true,
and queues the work again:

    if (refcount_dec_and_test(&wl->refcount)) {
        if (!wl->enabled)
            goto out_unlock;
        
        __intel_dmc_wl_release(display);
        ...

Then CPU1 would acquire the lock, disable the wakelock, and set 
wl->enabled = false, but the work has already been re-queued.

When the queued intel_dmc_wl_work() executes later, it checks if refcount is
non-zero but doesn't check wl->enabled. It would then poll for
DMC_WAKELOCK_CTL_ACK and trigger the "DMC wakelock release timed out"
WARN_RATELIMIT since the wakelock was already disabled.

>  
>  	spin_lock_irqsave(&wl->lock, flags);
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261013161131.2572279-4-dibin.moolakadan.subrahmanian@intel.com?part=2