linux-toradex.git/drivers/gpu/drm/i915/i915_gem_execbuffer.c, branch v3.2.68

drm/i915: Only copy back the modified fields to userspace from execbuffer

2014-07-11T12:33:37+00:00

commit 9aab8bff7aa3bee567213ad3c1fdfb217bb980a2 upstream.

We only want to modifiy a single field in the userspace view of the
execbuffer command buffer, so explicitly change that rather than copy
everything back again.

This serves two purposes:

1. The single fields are much cheaper to copy (constant size so the
copy uses special case code) and much smaller than the whole array.

2. We modify the array for internal use that need to be masked from
the user.

Note: We need this backported since without it the next bugfix will
blow up when userspace recycles batchbuffers and relocations.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Signed-off-by: Daniel Vetter 
[bwh: Backported to 3.2: to_user_ptr() is open-coded]
Signed-off-by: Ben Hutchings

drm/i915: s/DRM_ERROR/DRM_DEBUG in i915_gem_execbuffer.c

2014-07-11T12:33:37+00:00

commit ff240199b6a3b0bec5ae9b6d26403dad38e8cb19 upstream.

These are all user-trigerable, so tune down their loudness a notch.
For some of these we have i-g-t tests (because they prevent
newly-discovered bugs), without this patches running the test suite
leaves behind a dirty dmesg.

Reviewed-by: Chris Wilson 
Signed-Off-by: Daniel Vetter 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

drm/i915: bounds check execbuffer relocation count

2013-03-27T02:41:13+00:00

commit 3118a4f652c7b12c752f3222af0447008f9b2368 upstream.

It is possible to wrap the counter used to allocate the buffer for
relocation copies. This could lead to heap writing overflows.

CVE-2013-0913

v3: collapse test, improve comment
v2: move check into validate_exec_list

Signed-off-by: Kees Cook 
Reported-by: Pinkie Pie
Reviewed-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
Signed-off-by: Ben Hutchings

drm/i915: Invalidate the relocation presumed_offsets along the slow path

2013-02-06T04:33:35+00:00

commit 262b6d363fcff16359c93bd58c297f961f6e6273 upstream.

In the slow path, we are forced to copy the relocations prior to
acquiring the struct mutex in order to handle pagefaults. We forgo
copying the new offsets back into the relocation entries in order to
prevent a recursive locking bug should we trigger a pagefault whilst
holding the mutex for the reservations of the execbuffer. Therefore, we
need to reset the presumed_offsets just in case the objects are rebound
back into their old locations after relocating for this exexbuffer - if
that were to happen we would assume the relocations were valid and leave
the actual pointers to the kernels dangling, instant hang.

Fixes regression from commit bcf50e2775bbc3101932d8e4ab8c7902aa4163b4
Author: Chris Wilson 
Date:   Sun Nov 21 22:07:12 2010 +0000

    drm/i915: Handle pagefaults in execbuffer user relocations

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55984
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Signed-off-by: Daniel Vetter 
Signed-off-by: Ben Hutchings

drm/i915: Mark untiled BLT commands as fenced on gen2/3

2012-10-17T02:50:12+00:00

commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba upstream.

The BLT commands on gen2/3 utilize the fence registers and so we cannot
modify any fences for the object whilst those commands are in flight.
Currently we marked tiled commands as occupying a fence, but forgot to
restrict the untiled commands from preventing a fence being assigned
before they were completed.

One side-effect is that we ten have to double check that a fence was
allocated for a fenced buffer during move-to-active.

Reported-by: Jiri Slaby 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43427
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47990
Reviewed-by: Daniel Vetter 
Testcase: i-g-t/tests/gem_tiled_after_untiled_blt
Tested-by: Daniel Vetter 
Signed-off-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
[bwh: Backported to 3.2: The nesting of if-statements in the old
 i915_gem_execbuffer_reserve() differs from pin_and_fence_object(),
 so don't move the assignment of obj->pending_fenced_gpu_access but
 adjust the boolean expression as recommended by Daniel Vetter.]
Signed-off-by: Ben Hutchings

drm/i915: fix integer overflow in i915_gem_do_execbuffer()

2012-05-11T12:14:40+00:00

commit 44afb3a04391a74309d16180d1e4f8386fdfa745 upstream.

On 32-bit systems, a large args->num_cliprects from userspace via ioctl
may overflow the allocation size, leading to out-of-bounds access.

This vulnerability was introduced in commit 432e58ed ("drm/i915: Avoid
allocation for execbuffer object list").

Signed-off-by: Xi Wang 
Reviewed-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
Signed-off-by: Ben Hutchings

drm/i915: fix integer overflow in i915_gem_execbuffer2()

2012-05-11T12:14:39+00:00

commit ed8cd3b2cd61004cab85380c52b1817aca1ca49b upstream.

On 32-bit systems, a large args->buffer_count from userspace via ioctl
may overflow the allocation size, leading to out-of-bounds access.

This vulnerability was introduced in commit 8408c282 ("drm/i915:
First try a normal large kmalloc for the temporary exec buffers").

Signed-off-by: Xi Wang 
Reviewed-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

drm/i915: Force sync command ordering (Gen6+)

2012-05-11T12:14:38+00:00

commit 84f9f938be4156e4baea466688bd6abae1c9e6ba upstream.

The docs say this is required for Gen7, and since the bit was added for
Gen6, we are also setting it there pit pf paranoia. Particularly as
Chris points out, if PIPE_CONTROL counts as a 3d state packet.

This was found through doc inspection by Ken and applies to Gen6+;

Reported-by: Kenneth Graunke 
Signed-off-by: Ben Widawsky 
Reviewed-by: Chris Wilson 
Reviewed-by: Daniel Vetter 
Reviewed-by: Eric Anholt 
Signed-off-by: Keith Packard 
Signed-off-by: Ben Hutchings

drm/i915: relative_constants_mode race fix

2012-05-11T12:14:38+00:00

commit e2971bdab2b761683353da383c0fd5ac704d1cca upstream.

dev_priv keeps track of the current addressing mode that gets set at
execbuffer time. Unfortunately the existing code was doing this before
acquiring struct_mutex which leaves a race with another thread also
doing an execbuffer. If that wasn't bad enough, relocate_slow drops
struct_mutex which opens a much more likely error where another thread
comes in and modifies the state while relocate_slow is being slow.

The solution here is to just defer setting this state until we
absolutely need it, and we know we'll have struct_mutex for the
remainder of our code path.

v2: Keith noticed a bug in the original patch.

Signed-off-by: Ben Widawsky 
Reviewed-by: Daniel Vetter 
Signed-off-by: Keith Packard 
Signed-off-by: Ben Hutchings

drm/i915: Disable semaphores by default on SNB

2011-12-27T05:07:26+00:00

Semaphores still cause problems on some machines:

> From Udo Steinberg:
>
> With Linux-3.2-rc6 I'm frequently seeing GPU hangs when large amounts of
> text scroll in an xterm, such as when extracting a tar archive. Such as this
> one (note the timestamps):
>
>  I can reproduce it fairly easily with something
>  as simple as:
>
>	  while true; do dmesg; done

This patch turns them off on SNB while leaving them on for IVB.

Reported-by: Udo Steinberg 
Cc: Daniel Vetter 
Cc: Eugeni Dodonov 
Signed-off-by: Keith Packard 
Signed-off-by: Linus Torvalds