linux-stable.git/drivers/gpu, branch v4.1.41

drm/ttm: fix use-after-free races in vm fault handling

2017-06-13T13:29:21+00:00

[ Upstream commit 3089c1df10e2931b1d72d2ffa7d86431084c86b3 ]

The vm fault handler relies on the fact that the VMA owns a reference
to the BO. However, once mmap_sem is released, other tasks are free to
destroy the VMA, which can lead to the BO being freed. Fix two code
paths where that can happen, both related to vm fault retries.

Found via a lock debugging warning which flagged &bo->wu_mutex as
locked while being destroyed.

Fixes: cbe12e74ee4e ("drm/ttm: Allow vm fault retries")
Signed-off-by: Nicolai Hähnle 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/msm: Expose our reservation object when exporting a dmabuf.

2017-06-08T10:42:00+00:00

[ Upstream commit 43523eba79bda8f5b4c27f8ffe20ea078d20113a ]

Without this, polling on the dma-buf (and presumably other devices
synchronizing against our rendering) would return immediately, even
while the BO was busy.

Signed-off-by: Eric Anholt 
Reviewed-by: Daniel Vetter 
Cc: stable@vger.kernel.org
Cc: Rob Clark 
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Reviewed-by: Rob Clark 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin

drm/radeon: Unbreak HPD handling for r600+

2017-06-08T10:41:59+00:00

[ Upstream commit 3d18e33735a02b1a90aecf14410bf3edbfd4d3dc ]

We end up reading the interrupt register for HPD5, and then writing it
to HPD6 which on systems without anything using HPD5 results in
permanently disabling hotplug on one of the display outputs after the
first time we acknowledge a hotplug interrupt from the GPU.

This code is really bad. But for now, let's just fix this. I will
hopefully have a large patch series to refactor all of this soon.

Reviewed-by: Christian König 
Signed-off-by: Lyude 
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/gma500/psb: Actually use VBT mode when it is found

2017-06-08T10:12:47+00:00

[ Upstream commit 82bc9a42cf854fdf63155759c0aa790bd1f361b0 ]

With LVDS we were incorrectly picking the pre-programmed mode instead of
the prefered mode provided by VBT. Make sure we pick the VBT mode if
one is provided. It is likely that the mode read-out code is still wrong
but this patch fixes the immediate problem on most machines.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78562
Cc: 
Signed-off-by: Patrik Jakobsson 
Link: http://patchwork.freedesktop.org/patch/msgid/20170418114332.12183-1-patrik.r.jakobsson@gmail.com
Signed-off-by: Sasha Levin

drm/vmwgfx: fix integer overflow in vmw_surface_define_ioctl()

2017-05-17T19:07:44+00:00

[ Upstream commit e7e11f99564222d82f0ce84bd521e57d78a6b678 ]

In vmw_surface_define_ioctl(), the 'num_sizes' is the sum of the
'req->mip_levels' array. This array can be assigned any value from
the user space. As both the 'num_sizes' and the array is uint32_t,
it is easy to make 'num_sizes' overflow. The later 'mip_levels' is
used as the loop count. This can lead an oob write. Add the check of
'req->mip_levels' to avoid this.

Cc: 
Signed-off-by: Li Qiang 
Reviewed-by: Thomas Hellstrom 
Signed-off-by: Sasha Levin

drm/vmwgfx: Remove getparam error message

2017-05-17T19:07:44+00:00

[ Upstream commit 53e16798b0864464c5444a204e1bb93ae246c429 ]

The mesa winsys sometimes uses unimplemented parameter requests to
check for features. Remove the error message to avoid bloating the
kernel log.

Cc: 
Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Sinclair Yeh 
Signed-off-by: Sasha Levin

drm/vmwgfx: avoid calling vzalloc with a 0 size in vmw_get_cap_3d_ioctl()

2017-05-17T19:07:44+00:00

[ Upstream commit 63774069d9527a1aeaa4aa20e929ef5e8e9ecc38 ]

In vmw_get_cap_3d_ioctl(), a user can supply 0 for a size that is
used in vzalloc(). This eventually calls dump_stack() (in warn_alloc()),
which can leak useful addresses to dmesg.

Add check to avoid a size of 0.

Cc: 
Signed-off-by: Murray McAllister 
Reviewed-by: Sinclair Yeh 
Signed-off-by: Sasha Levin

drm/vmwgfx: NULL pointer dereference in vmw_surface_define_ioctl()

2017-05-17T19:07:44+00:00

[ Upstream commit 36274ab8c596f1240c606bb514da329add2a1bcd ]

Before memory allocations vmw_surface_define_ioctl() checks the
upper-bounds of a user-supplied size, but does not check if the
supplied size is 0.

Add check to avoid NULL pointer dereferences.

Cc: 
Signed-off-by: Murray McAllister 
Reviewed-by: Sinclair Yeh 
Signed-off-by: Sasha Levin

drm/vmwgfx: Type-check lookups of fence objects

2017-05-17T19:07:44+00:00

[ Upstream commit f7652afa8eadb416b23eb57dec6f158529942041 ]

A malicious caller could otherwise hand over handles to other objects
causing all sorts of interesting problems.

Testing done: Ran a Fedora 25 desktop using both Xorg and
gnome-shell/Wayland.

Cc: 
Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
Signed-off-by: Sasha Levin

drm/radeon: Override fpfn for all VRAM placements in radeon_evict_flags

2017-05-17T19:07:44+00:00

[ Upstream commit ce4b4f228e51219b0b79588caf73225b08b5b779 ]

We were accidentally only overriding the first VRAM placement. For BOs
with the RADEON_GEM_NO_CPU_ACCESS flag set,
radeon_ttm_placement_from_domain creates a second VRAM placment with
fpfn == 0. If VRAM is almost full, the first VRAM placement with
fpfn > 0 may not work, but the second one with fpfn == 0 always will
(the BO's current location trivially satisfies it). Because "moving"
the BO to its current location puts it back on the LRU list, this
results in an infinite loop.

Fixes: 2a85aedd117c ("drm/radeon: Try evicting from CPU accessible to
                      inaccessible VRAM first")
Reported-by: Zachary Michaels 
Reported-and-Tested-by: Julien Isorce 
Reviewed-by: Christian König 
Reviewed-by: Alex Deucher 
Signed-off-by: Michel Dänzer 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org

Signed-off-by: Sasha Levin