[Intel-gfx] [PATCH] drm/i915/psr: Fix race in intel_psr_work()

[Chris Wilson]

Quoting Dhinakaran Pandiyan (2018-06-23 05:45:06)
> commit 5422b37c907e ("drm/i915/psr: Kill delays when activating psr
> back.") switched from delayed work to the plain variant and while doing so
> remove the check for work_busy() before scheduling a PSR activation.
> This appears to cause consecutive executions of psr_activate() in this
> scenario - after a worker picks up the PSR work item for execution and
> before the work function can acquire the PSR mutex, a psr_flush() can
> get hold of the mutex and schedule another PSR work. Without a psr_exit()
> between two psr_activate() calls, the warning messages get printed.

Ok, that would explain the second work.

> Further, since we drop the mutex in the midst of psr_work() to wait for
> PSR to idle, another work item can also get scheduled. Fix this by
> returning if PSR was already active.
> 
> Note:
> I am not 100% sure this is what is going on as I could not reproduce
> the bug (https://bugs.freedesktop.org/show_bug.cgi?id=106948)
> 
> This patch sort of defeats the point of the WARN_ON()s in psr_activate()
> now, do we still need them?

WARN_ON(active), yup. Seems reasonable to keep for the moment.
WARN_ON(hw_state) would be worth keeping for some time. Hmm, shouldn't
it be checking both PSR_CTL irrespective of intended mode. After
switching psr1 to psr2 we should check that psr1 is disabled as well,
and vice versa.

> Cc: Rodrigo Vivi <rodrigo.vivi at intel.com>
> Cc: Chris Wilson <chris at chris-wilson.co.uk>
> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan at intel.com>
Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
-Chris