linux-kernel - Re: [PATCH] Revert "drm/i915: Switch planes from transitional helpers to full atomic helpers"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 3 Mar 2015 17:44:25 +0100
From:	Daniel Vetter <daniel@...ll.ch>
To:	Intel Graphics Development <intel-gfx@...ts.freedesktop.org>
Cc:	DRI Development <dri-devel@...ts.freedesktop.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Matt Roper <matthew.d.roper@...el.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Paul Bolle <pebolle@...cali.nl>,
	Daniel Vetter <daniel.vetter@...el.com>
Subject: Re: [PATCH] Revert "drm/i915: Switch planes from transitional
 helpers to full atomic helpers"

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@...el.com>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> Cc: Paul Bolle <pebolle@...cali.nl>
> Signed-off-by: Daniel Vetter <daniel.vetter@...el.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
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/