| 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
| ||
|
Message-Id: <20120330194850.012225138@linuxfoundation.org> Date: Fri, 30 Mar 2012 12:49:46 -0700 From: Greg KH <gregkh@...uxfoundation.org> To: linux-kernel@...r.kernel.org, stable@...r.kernel.org Cc: torvalds@...ux-foundation.org, akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk, Chris Wilson <chris@...is-wilson.co.uk>, Daniel Vetter <daniel.vetter@...ll.ch>, Eugeni Dodonov <eugeni.dodonov@...el.com> Subject: [ 073/149] drm/i915: Only clear the GPU domains upon a successful finish 3.2-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chris Wilson <chris@...is-wilson.co.uk> commit c501ae7f332cdaf42e31af30b72b4b66cbbb1604 upstream. By clearing the GPU read domains before waiting upon the buffer, we run the risk of the wait being interrupted and the domains prematurely cleared. The next time we attempt to wait upon the buffer (after userspace handles the signal), we believe that the buffer is idle and so skip the wait. There are a number of bugs across all generations which show signs of an overly haste reuse of active buffers. Such as: https://bugs.freedesktop.org/show_bug.cgi?id=29046 https://bugs.freedesktop.org/show_bug.cgi?id=35863 https://bugs.freedesktop.org/show_bug.cgi?id=38952 https://bugs.freedesktop.org/show_bug.cgi?id=40282 https://bugs.freedesktop.org/show_bug.cgi?id=41098 https://bugs.freedesktop.org/show_bug.cgi?id=41102 https://bugs.freedesktop.org/show_bug.cgi?id=41284 https://bugs.freedesktop.org/show_bug.cgi?id=42141 A couple of those pre-date i915_gem_object_finish_gpu(), so may be unrelated (such as a wild write from a userspace command buffer), but this does look like a convincing cause for most of those bugs. Signed-off-by: Chris Wilson <chris@...is-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@...ll.ch> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@...el.com> Signed-off-by: Daniel Vetter <daniel.vetter@...ll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org> --- drivers/gpu/drm/i915/i915_gem.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3084,10 +3084,13 @@ i915_gem_object_finish_gpu(struct drm_i9 return ret; } + ret = i915_gem_object_wait_rendering(obj); + if (ret) + return ret; + /* Ensure that we invalidate the GPU's caches and TLBs. */ obj->base.read_domains &= ~I915_GEM_GPU_DOMAINS; - - return i915_gem_object_wait_rendering(obj); + return 0; } /** -- 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/
Powered by blists - more mailing lists