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

drm/i915: Stop using RP_DOWN_EI on Baytrail

2017-04-18T05:14:34+00:00

commit 8f68d591d4765b2e1ce9d916ac7bc5583285c4ad upstream.

On Baytrail, we manually calculate busyness over the evaluation interval
to avoid issues with miscaluations with RC6 enabled. However, it turns
out that the DOWN_EI interrupt generator is completely bust - it
operates in two modes, continuous or never. Neither of which are
conducive to good behaviour. Stop unmask the DOWN_EI interrupt and just
compute everything from the UP_EI which does seem to correspond to the
desired interval.

v2: Fixup gen6_rps_pm_mask() as well
v3: Inline vlv_c0_above() to combine the now identical elapsed
calculation for up/down and simplify the threshold testing

Fixes: 43cf3bf084ba ("drm/i915: Improved w/a for rps on Baytrail")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Link: http://patchwork.freedesktop.org/patch/msgid/20170309211232.28878-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala 
Link: http://patchwork.freedesktop.org/patch/msgid/20170313170617.31564-1-chris@chris-wilson.co.uk
(cherry picked from commit e0e8c7cb6eb68e9256de2d8cbeb481d3701c05ac)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3

2017-04-18T05:14:34+00:00

commit 34dc8993eef63681b062871413a9484008a2a78f upstream.

Certain Baytrails, namely the 4 cpu core variants, have been
plaqued by spurious system hangs, mostly occurring with light loads.

Multiple bisects by various people point to a commit which changes the
reclocking strategy for Baytrail to follow its bigger brethen:
commit 8fb55197e64d ("drm/i915: Agressive downclocking on Baytrail")

There is also a review comment attached to this commit from Deepak S
on avoiding punit access on Cherryview and thus it was excluded on
common reclocking path. By taking the same approach and omitting
the punit access by not tweaking the thresholds when the hardware
has been asked to move into different frequency, considerable gains
in stability have been observed.

With J1900 box, light render/video load would end up in system hang
in usually less than 12 hours. With this patch applied, the cumulative
uptime has now been 34 days without issues. To provoke system hang,
light loads on both render and bsd engines in parallel have been used:
glxgears >/dev/null 2>/dev/null &
mpv --vo=vaapi --hwdec=vaapi --loop=inf vid.mp4

So far, author has not witnessed system hang with above load
and this patch applied. Reports from the tenacious people at
kernel bugzilla are also promising.

Considering that the punit access frequency with this patch is
considerably less, there is a possibility that this will push
the, still unknown, root cause past the triggering point on most loads.

But as we now can reliably reproduce the hang independently,
we can reduce the pain that users are having and use a
static thresholds until a root cause is found.

v3: don't break debugfs and simplification (Chris Wilson)

References: https://bugzilla.kernel.org/show_bug.cgi?id=109051
Cc: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Len Brown 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: fritsch@xbmc.org
Cc: miku@iki.fi
Cc: Ezequiel Garcia 
CC: Michal Feix 
Cc: Hans de Goede 
Cc: Deepak S 
Cc: Jarkko Nikula 
Acked-by: Daniel Vetter 
Acked-by: Chris Wilson 
Signed-off-by: Mika Kuoppala 
Link: http://patchwork.freedesktop.org/patch/msgid/1487166779-26945-1-git-send-email-mika.kuoppala@intel.com
(cherry picked from commit 6067a27d1f0184596d51decbac1c1fdc4acb012f)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: fix integer overflow in vmw_surface_define_ioctl()

2017-04-12T10:38:33+00:00

commit e7e11f99564222d82f0ce84bd521e57d78a6b678 upstream.

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.

Signed-off-by: Li Qiang 
Reviewed-by: Thomas Hellstrom 
Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Remove getparam error message

2017-04-12T10:38:33+00:00

commit 53e16798b0864464c5444a204e1bb93ae246c429 upstream.

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

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Sinclair Yeh 
Signed-off-by: Greg Kroah-Hartman

drm/ttm, drm/vmwgfx: Relax permission checking when opening surfaces

2017-04-12T10:38:33+00:00

commit fe25deb7737ce6c0879ccf79c99fa1221d428bf2 upstream.

Previously, when a surface was opened using a legacy (non prime) handle,
it was verified to have been created by a client in the same master realm.
Relax this so that opening is also allowed recursively if the client
already has the surface open.

This works around a regression in svga mesa where opening of a shared
surface is used recursively to obtain surface information.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
Signed-off-by: Greg Kroah-Hartman

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

2017-04-12T10:38:32+00:00

commit 63774069d9527a1aeaa4aa20e929ef5e8e9ecc38 upstream.

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.

Signed-off-by: Murray McAllister 
Reviewed-by: Sinclair Yeh 
Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: NULL pointer dereference in vmw_surface_define_ioctl()

2017-04-12T10:38:32+00:00

commit 36274ab8c596f1240c606bb514da329add2a1bcd upstream.

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.

Signed-off-by: Murray McAllister 
Reviewed-by: Sinclair Yeh 
Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Type-check lookups of fence objects

2017-04-12T10:38:32+00:00

commit f7652afa8eadb416b23eb57dec6f158529942041 upstream.

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.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
Signed-off-by: Greg Kroah-Hartman

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

2017-04-08T07:53:31+00:00

commit ce4b4f228e51219b0b79588caf73225b08b5b779 upstream.

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 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: add missing irq.h include

2017-03-26T10:13:18+00:00

commit e9c5e7402dad6f4f04c2430db6f283512bcd4392 upstream.

this fixes the build on arm.

Signed-off-by: Dave Airlie 
Cc: Sumit Semwal 
Signed-off-by: Greg Kroah-Hartman