| Message ID | 1425310520-3421-1-git-send-email-daniel.vetter@ffwll.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Mar 02, 2015 at 04:35:20PM +0100, Daniel Vetter wrote: > This reverts commit 3f678c96abb43a977d2ea41aefccdc49e8a3e896. > > We've been a bit too optimistic with this one here :( > > The trouble is that internally we're still using these plane > update/disable hooks. Which was totally ok pre-atomic since the drm > core did all the book-keeping updating and these just mostly updated > hw state. But with atomic there's lots more going on, and it causes > heaps of trouble with the load detect code. > > This one specifically cause a deadlock since both the load detect code > and the nested plane atomic helper functions tried to grab the same > locks. It only blows up because of the evil tricks though we play with > the implicit ww acquire context. > > Applying this revert unearths the NULL deref on already freed > framebuffer objects reported as a regression in 4.0 by various people. > > Fixing this will be fairly invasive, hence revert even for the > 4.1-next queue. > > Cc: Matt Roper <matthew.d.roper@intel.com> > Cc: Linus Torvalds <torvalds@linux-foundation.org> > Cc: Paul Bolle <pebolle@tiscali.nl> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Queued for -next with Matt's ack. -Daniel > --- > Just to make it really clear: This is 4.1-next material. It's simply > the explanation for why we didn't notice the oops ourselves. The 4.0 > oops itself looks like some glue lacking in the load detect code, > still working on that one. > -Daniel > --- > drivers/gpu/drm/i915/intel_display.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c > index 3156d77b2215..cc3305e30c1b 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -12179,8 +12179,8 @@ void intel_plane_destroy(struct drm_plane *plane) > } > > const struct drm_plane_funcs intel_plane_funcs = { > - .update_plane = drm_atomic_helper_update_plane, > - .disable_plane = drm_atomic_helper_disable_plane, > + .update_plane = drm_plane_helper_update, > + .disable_plane = drm_plane_helper_disable, > .destroy = intel_plane_destroy, > .set_property = drm_atomic_helper_plane_set_property, > .atomic_get_property = intel_plane_atomic_get_property, > -- > 1.8.4.rc3 >
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 3156d77b2215..cc3305e30c1b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -12179,8 +12179,8 @@ void intel_plane_destroy(struct drm_plane *plane) } const struct drm_plane_funcs intel_plane_funcs = { - .update_plane = drm_atomic_helper_update_plane, - .disable_plane = drm_atomic_helper_disable_plane, + .update_plane = drm_plane_helper_update, + .disable_plane = drm_plane_helper_disable, .destroy = intel_plane_destroy, .set_property = drm_atomic_helper_plane_set_property, .atomic_get_property = intel_plane_atomic_get_property,
This reverts commit 3f678c96abb43a977d2ea41aefccdc49e8a3e896. We've been a bit too optimistic with this one here :( The trouble is that internally we're still using these plane update/disable hooks. Which was totally ok pre-atomic since the drm core did all the book-keeping updating and these just mostly updated hw state. But with atomic there's lots more going on, and it causes heaps of trouble with the load detect code. This one specifically cause a deadlock since both the load detect code and the nested plane atomic helper functions tried to grab the same locks. It only blows up because of the evil tricks though we play with the implicit ww acquire context. Applying this revert unearths the NULL deref on already freed framebuffer objects reported as a regression in 4.0 by various people. Fixing this will be fairly invasive, hence revert even for the 4.1-next queue. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> --- Just to make it really clear: This is 4.1-next material. It's simply the explanation for why we didn't notice the oops ourselves. The 4.0 oops itself looks like some glue lacking in the load detect code, still working on that one. -Daniel --- drivers/gpu/drm/i915/intel_display.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)