summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_pm.c
diff options
context:
space:
mode:
authorVille Syrjälä <ville.syrjala@linux.intel.com>2020-05-27 23:02:45 +0300
committerJoonas Lahtinen <joonas.lahtinen@linux.intel.com>2020-06-02 16:35:24 +0300
commit882f38b7f6c406e7229e72ee4328b7f1d5938ae7 (patch)
tree943cdaa94b1f96726c2bb5d6cf12f189763e60c7 /drivers/gpu/drm/i915/intel_pm.c
parent0e386959272e4adf192867681a65cc0aa580c247 (diff)
downloadlinux-882f38b7f6c406e7229e72ee4328b7f1d5938ae7.tar.bz2
drm/i915: Fix global state use-after-frees with a refcount
While the current locking/serialization of the global state suffices for protecting the obj->state access and the actual hardware reprogramming, we do have a problem with accessing the old/new states during nonblocking commits. The state computation and swap will be protected by the crtc locks, but the commit_tails can finish out of order, thus also causing the atomic states to be cleaned up out of order. This would mean the commit that started first but finished last has had its new state freed as the no-longer-needed old state by the other commit. To fix this let's just refcount the states. obj->state amounts to one reference, and the intel_atomic_state holds extra references to both its new and old global obj states. Fixes: 0ef1905ecf2e ("drm/i915: Introduce better global state handling") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200527200245.13184-1-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (cherry picked from commit f8c86ffa2800adc80adc679c84c45e0c6b027374) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Diffstat (limited to 'drivers/gpu/drm/i915/intel_pm.c')
0 files changed, 0 insertions, 0 deletions