linux-toradex.git/drivers/gpu/drm, branch v4.9.45

drm/i915: Fix out-of-bounds array access in bdw_load_gamma_lut

2017-08-16T20:43:18+00:00

commit 5279fc7724ae3a82c9cfe5b09c1fb07ff0e41056 upstream.

bdw_load_gamma_lut is writing beyond the array to the maximum value.
The intend of the function is to clamp values > 1 to 1, so write
the intended color to the max register.

This fixes the following KASAN warning:

[  197.020857] [IGT] kms_pipe_color: executing
[  197.063434] [IGT] kms_pipe_color: starting subtest ctm-0-25-pipe0
[  197.078989] ==================================================================
[  197.079127] BUG: KASAN: slab-out-of-bounds in bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915]
[  197.079188] Read of size 2 at addr ffff8800d38db150 by task kms_pipe_color/1839
[  197.079208] CPU: 2 PID: 1839 Comm: kms_pipe_color Tainted: G     U 4.13.0-rc1-patser+ #5211
[  197.079215] Hardware name: NUC5i7RYB, BIOS RYBDWi35.86A.0246.2015.0309.1355 03/09/2015
[  197.079220] Call Trace:
[  197.079230]  dump_stack+0x68/0x9e
[  197.079239]  print_address_description+0x6f/0x250
[  197.079251]  kasan_report+0x216/0x370
[  197.079374]  ? bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915]
[  197.079451]  ? gen8_write16+0x4e0/0x4e0 [i915]
[  197.079460]  __asan_report_load2_noabort+0x14/0x20
[  197.079535]  bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915]
[  197.079612]  broadwell_load_luts+0x1df/0x550 [i915]
[  197.079690]  intel_color_load_luts+0x7b/0x80 [i915]
[  197.079764]  intel_begin_crtc_commit+0x138/0x760 [i915]
[  197.079783]  drm_atomic_helper_commit_planes_on_crtc+0x1a3/0x820 [drm_kms_helper]
[  197.079859]  ? intel_pre_plane_update+0x571/0x580 [i915]
[  197.079937]  intel_update_crtc+0x238/0x330 [i915]
[  197.080016]  intel_update_crtcs+0x10f/0x210 [i915]
[  197.080092]  intel_atomic_commit_tail+0x1552/0x3340 [i915]
[  197.080101]  ? _raw_spin_unlock+0x3c/0x40
[  197.080110]  ? __queue_work+0xb40/0xbf0
[  197.080188]  ? skl_update_crtcs+0xc00/0xc00 [i915]
[  197.080195]  ? trace_hardirqs_on+0xd/0x10
[  197.080269]  ? intel_atomic_commit_ready+0x128/0x13c [i915]
[  197.080329]  ? __i915_sw_fence_complete+0x5b8/0x6d0 [i915]
[  197.080336]  ? debug_object_activate+0x39e/0x580
[  197.080397]  ? i915_sw_fence_await+0x30/0x30 [i915]
[  197.080409]  ? __might_sleep+0x15b/0x180
[  197.080483]  intel_atomic_commit+0x944/0xa70 [i915]
[  197.080490]  ? refcount_dec_and_test+0x11/0x20
[  197.080567]  ? intel_atomic_commit_tail+0x3340/0x3340 [i915]
[  197.080597]  ? drm_atomic_crtc_set_property+0x303/0x580 [drm]
[  197.080674]  ? intel_atomic_commit_tail+0x3340/0x3340 [i915]
[  197.080704]  drm_atomic_commit+0xd7/0xe0 [drm]
[  197.080722]  drm_atomic_helper_crtc_set_property+0xec/0x130 [drm_kms_helper]
[  197.080749]  drm_mode_crtc_set_obj_prop+0x7d/0xb0 [drm]
[  197.080775]  drm_mode_obj_set_property_ioctl+0x50b/0x5d0 [drm]
[  197.080783]  ? __might_fault+0x104/0x180
[  197.080809]  ? drm_mode_obj_find_prop_id+0x160/0x160 [drm]
[  197.080838]  ? drm_mode_obj_find_prop_id+0x160/0x160 [drm]
[  197.080861]  drm_ioctl_kernel+0x154/0x1a0 [drm]
[  197.080885]  drm_ioctl+0x624/0x8f0 [drm]
[  197.080910]  ? drm_mode_obj_find_prop_id+0x160/0x160 [drm]
[  197.080934]  ? drm_getunique+0x210/0x210 [drm]
[  197.080943]  ? __handle_mm_fault+0x1bd0/0x1ce0
[  197.080949]  ? lock_downgrade+0x610/0x610
[  197.080957]  ? __lru_cache_add+0x15a/0x180
[  197.080967]  do_vfs_ioctl+0xd92/0xe40
[  197.080975]  ? ioctl_preallocate+0x1b0/0x1b0
[  197.080982]  ? selinux_capable+0x20/0x20
[  197.080991]  ? __do_page_fault+0x7b7/0x9a0
[  197.080997]  ? lock_downgrade+0x5bb/0x610
[  197.081007]  ? security_file_ioctl+0x57/0x90
[  197.081016]  SyS_ioctl+0x4e/0x80
[  197.081024]  entry_SYSCALL_64_fastpath+0x18/0xad
[  197.081030] RIP: 0033:0x7f61f287a987
[  197.081035] RSP: 002b:00007fff7d44d188 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[  197.081043] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f61f287a987
[  197.081048] RDX: 00007fff7d44d1c0 RSI: 00000000c01864ba RDI: 0000000000000003
[  197.081053] RBP: 00007f61f2b3eb00 R08: 0000000000000059 R09: 0000000000000000
[  197.081058] R10: 0000002ea5c4a290 R11: 0000000000000246 R12: 00007f61f2b3eb58
[  197.081063] R13: 0000000000001010 R14: 00007f61f2b3eb58 R15: 0000000000002702

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101659
Signed-off-by: Maarten Lankhorst 
Reported-by: Martin Peres 
Cc: Martin Peres 
Fixes: 82cf435b3134 ("drm/i915: Implement color management on bdw/skl/bxt/kbl")
Cc: Shashank Sharma 
Cc: Kiran S Kumar 
Cc: Kausal Malladi 
Cc: Lionel Landwerlin 
Cc: Matt Roper 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: intel-gfx@lists.freedesktop.org
Link: https://patchwork.freedesktop.org/patch/msgid/20170724091431.24251-1-maarten.lankhorst@linux.intel.com
Reviewed-by: Lionel Landwerlin 
(cherry picked from commit 09a92bc8773b4314e02b478e003fe5936ce85adb)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/etnaviv: Fix off-by-one error in reloc checking

2017-08-16T20:43:18+00:00

commit d6f756e09f01ea7a0efbbcef269a1e384a35d824 upstream.

A relocation pointing to the last four bytes of a buffer can
legitimately happen in the case of small vertex buffers.

Signed-off-by: Wladimir J. van der Laan 
Reviewed-by: Philipp Zabel 
Reviewed-by: Christian Gmeiner 
Signed-off-by: Lucas Stach 
Signed-off-by: Greg Kroah-Hartman

drm/virtio: fix framebuffer sparse warning

2017-08-11T15:49:35+00:00

[ Upstream commit 71d3f6ef7f5af38dea2975ec5715c88bae92e92d ]

virtio uses normal ram as backing storage for the framebuffer, so we
should assign the address to new screen_buffer (added by commit
17a7b0b4d9749f80d365d7baff5dec2f54b0e992) instead of screen_base.

Reported-by: Michael S. Tsirkin 
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Fix undue fallthroughs in golden registers initialization

2017-08-11T15:49:29+00:00

commit 5694785cf09bf0e7bd8e5f62361ea34fa162a4a0 upstream.

As I was staring at the si_init_golden_registers code, I noticed that
the Pitcairn initialization silently falls through the Cape Verde
initialization, and the Oland initialization falls through the Hainan
initialization. However there is no comment stating that this is
intentional, and the radeon driver doesn't have any such fallthrough,
so I suspect this is not supposed to happen.

Signed-off-by: Jean Delvare 
Fixes: 62a37553414a ("drm/amdgpu: add si implementation v10")
Cc: Ken Wang 
Cc: Alex Deucher 
Cc: "Marek Olšák" 
Cc: "Christian König" 
Cc: Flora Cui 
Reviewed-by: Marek Olšák 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/msm: Verify that MSM_SUBMIT_BO_FLAGS are set

2017-08-07T01:59:45+00:00

[ Upstream commit a6cb3b864b21b7345f824a4faa12b723c8aaf099 ]

For every submission buffer object one of MSM_SUBMIT_BO_WRITE
and MSM_SUBMIT_BO_READ must be set (and nothing else). If we
allowed zero then the buffer object would never get queued to
be unreferenced.

Signed-off-by: Jordan Crouse 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/msm: Put back the vaddr in submit_reloc()

2017-08-07T01:59:45+00:00

[ Upstream commit 6490abc4bc35fa4f3bdb9c7e49096943c50e29ea ]

The error cases in submit_reloc() need to put back the virtual
address of the bo before failling. Add a single failure path
for the function.

Signed-off-by: Jordan Crouse 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/msm: Ensure that the hardware write pointer is valid

2017-08-07T01:59:45+00:00

[ Upstream commit 88b333b0ed790f9433ff542b163bf972953b74d3 ]

Currently the value written to CP_RB_WPTR is calculated on the fly as
(rb->next - rb->start). But as the code is designed rb->next is wrapped
before writing the commands so if a series of commands happened to
fit perfectly in the ringbuffer, rb->next would end up being equal to
rb->size / 4 and thus result in an out of bounds address to CP_RB_WPTR.

The easiest way to fix this is to mask WPTR when writing it to the
hardware; it makes the hardware happy and the rest of the ringbuffer
math appears to work and there isn't any point in upsetting anything.

Signed-off-by: Jordan Crouse 
[squash in is_power_of_2() check]
Signed-off-by: Rob Clark 

Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm: rcar-du: Simplify and fix probe error handling

2017-08-07T01:59:41+00:00

commit 4f7b0d263833928e947e172eff2d2997179c5cb9 upstream.

It isn't safe to call drm_dev_unregister() without first initializing
mode setting with drm_mode_config_init(). This leads to a crash if
either IO memory can't be remapped or vblank initialization fails.

Fix this by reordering the initialization sequence. Move vblank
initialization after the drm_mode_config_init() call, and move IO
remapping before drm_dev_alloc() to avoid the need to perform clean up
in case of failure.

While at it remove the explicit drm_vblank_cleanup() call from
rcar_du_remove() as the drm_dev_unregister() function already cleans up
vblank.

Signed-off-by: Laurent Pinchart 
Signed-off-by: thongsyho 
Signed-off-by: Nhan Nguyen 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/bar/gf100: fix access to upper half of BAR2

2017-08-07T01:59:41+00:00

commit 38bcb208f60924a031b9f809f7cd252ea4a94e5f upstream.

Bit 30 being set causes the upper half of BAR2 to stay in physical mode,
mapped over the end of VRAM, even when the rest of the BAR has been set
to virtual mode.

We inherited our initial value from RM, but I'm not aware of any reason
we need to keep it that way.

This fixes severe GPU hang/lockup issues revealed by Wayland on F26.

Shout-out to NVIDIA for the quick response with the potential cause!

Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/disp/nv50-: bump max chans to 21

2017-08-07T01:59:41+00:00

commit a90e049cacd965dade4dae7263b4d3fd550e78b6 upstream.

GP102's cursors go from chan 17..20. Increase the array size to hold
their data properly.

Fixes: e50fcff15f ("drm/nouveau/disp/gp102: fix cursor/overlay immediate channel indices")
Signed-off-by: Ilia Mirkin 
Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman