On Thu, Oct 17, 2013 at 09:27:41PM -0400, Ilija Hadzic wrote:
> (dropping stable at ... until we get the fix we can agree on)
>
> While looking through that function (drm_crtc_helper_set_config) to
> figure out what we really need to save and restore, I came across a
> piece of code that you added
(dropping stable at ... until we get the fix we can agree on)
While looking through that function (drm_crtc_helper_set_config) to
figure out what we really need to save and restore, I came across a
piece of code that you added in 25f397a4. The 'if (connector->dpms !=
DRM_MODE_DPMS_ON)' (line 719
On Thu, Oct 17, 2013 at 1:35 AM, Ilija Hadzic wrote:
> Embedding a mutex inside drm_crtc structure evokes a
> subtle and rare corruption in drm_crtc_helper_set_config
> failure-recovery path.
>
> Namely, if drm_crtc_helper_set_config takes the
> path under 'fail:' label *and* some other process
>
> Can't we instead just copy the few things we need to restore back?
> This wholesale structure copying has rather tricky semantics and is
> bound to trick up someone else in the future. And indeed we seem to
> have a similar (but less catastrophic) thing going on with crtc->fb I
> think.
Sure, it
Embedding a mutex inside drm_crtc structure evokes a
subtle and rare corruption in drm_crtc_helper_set_config
failure-recovery path.
Namely, if drm_crtc_helper_set_config takes the
path under 'fail:' label *and* some other process
has attempted to grab the crtc mutex (and got blocked),
restoring t
