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

drm/nouveau/mmu: qualify vmm during dtor

2020-01-23T07:21:38+00:00

commit 15516bf9abaa41421a6ded79a5a2fee86f9594e5 upstream.

If the BAR initialization failed it may leave the vmm structure in an
unitialized state, leading to a null-pointer-dereference when the vmm is
dereferenced during teardown.

Signed-off-by: Jon Derrick 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sushma Kalakota 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/bar/gf100: ensure BAR is mapped

2020-01-23T07:21:37+00:00

commit 12e08beb32d64b6070b718630490db83dd321c8c upstream.

If the BAR is zero size, it indicates it was never successfully mapped.
Ensure that the BAR is valid during initialization before attempting to
use it.

Signed-off-by: Jon Derrick 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sushma Kalakota 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/bar/nv50: check bar1 vmm return value

2020-01-23T07:21:37+00:00

commit 307a312df9c43fdea286ad17f748aaf777cc434a upstream.

Check bar1's new vmm creation return value for errors.

Signed-off-by: Jon Derrick 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sushma Kalakota 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Add missing include file

2020-01-23T07:21:30+00:00

commit ea38aa2ea5b0969776f0a47f174ce928a22be803 upstream.

Fix build error:
./drivers/gpu/drm/i915/selftests/i915_random.h: In function i915_prandom_u32_max_state:
./drivers/gpu/drm/i915/selftests/i915_random.h:48:23: error:
 implicit declaration of function mul_u32_u32; did you mean mul_u64_u32_div? [-Werror=implicit-function-declaration]
  return upper_32_bits(mul_u32_u32(prandom_u32_state(state), ep_ro));

Reported-by: Hulk Robot 
Fixes: 7ce5b6850b47 ("drm/i915/selftests: Use mul_u32_u32() for 32b x 32b -> 64b result")
Signed-off-by: YueHaibing 
Reviewed-by: Chris Wilson 
Signed-off-by: Chris Wilson 
Link: https://patchwork.freedesktop.org/patch/msgid/20200107135014.36472-1-yuehaibing@huawei.com
(cherry picked from commit 62bf5465b26d1f502430b9c654be7d16bf2e242d)
Signed-off-by: Joonas Lahtinen 
Signed-off-by: Greg Kroah-Hartman

drm/arm/mali: make malidp_mw_connector_helper_funcs static

2020-01-17T18:47:15+00:00

[ Upstream commit ac2917b01992c098b8d4e6837115e3ca347fdd90 ]

The malidp_mw_connector_helper_funcs is not referenced by name
outside of the file it is in, so make it static to avoid the
following warning:

drivers/gpu/drm/arm/malidp_mw.c:59:41: warning: symbol 'malidp_mw_connector_helper_funcs' was not declared. Should it be static?

Signed-off-by: Ben Dooks (Codethink) 
Signed-off-by: Liviu Dudau 
Link: https://patchwork.freedesktop.org/patch/msgid/20191217115309.2133503-1-ben.dooks@codethink.co.uk
Signed-off-by: Sasha Levin

drm/ttm: fix incrementing the page pointer for huge pages

2020-01-17T18:47:02+00:00

commit 453393369dc9806d2455151e329c599684762428 upstream.

When we increment the counter we need to increment the pointer as well.

Signed-off-by: Christian König 
Fixes: e16858a7e6e7 drm/ttm: fix start page for huge page check in ttm_put_pages()
Reviewed-by: Michel Dänzer 
Acked-by: Huang Rui 
Signed-off-by: Alex Deucher 
Cc: Zubin Mithra 
Signed-off-by: Greg Kroah-Hartman

drm/ttm: fix start page for huge page check in ttm_put_pages()

2020-01-17T18:47:02+00:00

commit ac1e516d5a4c56bf0cb4a3dfc0672f689131cfd4 upstream.

The first page entry is always the same with itself.

Signed-off-by: Christian König 
Reviewed-by: Michel Dänzer 
Reviewed-by: Junwei Zhang 
Reviewed-by: Huang Rui 
Signed-off-by: Alex Deucher 
Cc: Zubin Mithra 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix use-after-free when destroying GEM context

2020-01-17T18:46:58+00:00

This patch is a simplified fix to address a use-after-free in 4.14.x and
4.19.x stable kernels. The flaw is already fixed upstream, starting in
5.2, by commit 7dc40713618c ("drm/i915: Introduce a mutex for
file_priv->context_idr") as part of a more complex patch series that
isn't appropriate for backporting to stable kernels.

Expand mutex coverage, while destroying the GEM context, to include the
GEM context lookup step. This fixes a use-after-free detected by KASAN:

 ==================================================================
 BUG: KASAN: use-after-free in i915_ppgtt_close+0x2ca/0x2f0
 Write of size 1 at addr ffff8881368a8368 by task i915-poc/3124

 CPU: 0 PID: 3124 Comm: i915-poc Not tainted 4.14.164 #1
 Hardware name: HP HP Elite x2 1012 G1 /80FC, BIOS N85 Ver. 01.20 04/05/2017
 Call Trace:
  dump_stack+0xcd/0x12e
  ? _atomic_dec_and_lock+0x1b2/0x1b2
  ? i915_ppgtt_close+0x2ca/0x2f0
  ? printk+0x8f/0xab
  ? show_regs_print_info+0x53/0x53
  ? i915_ppgtt_close+0x2ca/0x2f0
  print_address_description+0x65/0x270
  ? i915_ppgtt_close+0x2ca/0x2f0
  kasan_report+0x251/0x340
  i915_ppgtt_close+0x2ca/0x2f0
  ? __radix_tree_insert+0x3f0/0x3f0
  ? i915_ppgtt_init_hw+0x7c0/0x7c0
  context_close+0x42e/0x680
  ? i915_gem_context_release+0x230/0x230
  ? kasan_kmalloc+0xa0/0xd0
  ? radix_tree_delete_item+0x1d4/0x250
  ? radix_tree_lookup+0x10/0x10
  ? inet_recvmsg+0x4b0/0x4b0
  ? kasan_slab_free+0x88/0xc0
  i915_gem_context_destroy_ioctl+0x236/0x300
  ? i915_gem_context_create_ioctl+0x360/0x360
  ? drm_dev_printk+0x1d0/0x1d0
  ? memcpy+0x34/0x50
  ? i915_gem_context_create_ioctl+0x360/0x360
  drm_ioctl_kernel+0x1b0/0x2b0
  ? drm_ioctl_permit+0x2a0/0x2a0
  ? avc_ss_reset+0xd0/0xd0
  drm_ioctl+0x6fe/0xa20
  ? i915_gem_context_create_ioctl+0x360/0x360
  ? drm_getstats+0x20/0x20
  ? put_unused_fd+0x260/0x260
  do_vfs_ioctl+0x189/0x12d0
  ? ioctl_preallocate+0x280/0x280
  ? selinux_file_ioctl+0x3a7/0x680
  ? selinux_bprm_set_creds+0xe30/0xe30
  ? security_file_ioctl+0x69/0xa0
  ? selinux_bprm_set_creds+0xe30/0xe30
  SyS_ioctl+0x6f/0x80
  ? __sys_sendmmsg+0x4a0/0x4a0
  ? do_vfs_ioctl+0x12d0/0x12d0
  do_syscall_64+0x214/0x5f0
  ? __switch_to_asm+0x31/0x60
  ? __switch_to_asm+0x25/0x60
  ? __switch_to_asm+0x31/0x60
  ? syscall_return_slowpath+0x2c0/0x2c0
  ? copy_overflow+0x20/0x20
  ? __switch_to_asm+0x25/0x60
  ? syscall_return_via_sysret+0x2a/0x7a
  ? prepare_exit_to_usermode+0x200/0x200
  ? __switch_to_asm+0x31/0x60
  ? __switch_to_asm+0x31/0x60
  ? __switch_to_asm+0x25/0x60
  ? __switch_to_asm+0x25/0x60
  ? __switch_to_asm+0x31/0x60
  ? __switch_to_asm+0x25/0x60
  ? __switch_to_asm+0x31/0x60
  ? __switch_to_asm+0x31/0x60
  ? __switch_to_asm+0x25/0x60
  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
 RIP: 0033:0x7f7fda5115d7
 RSP: 002b:00007f7eec317ec8 EFLAGS: 00000286 ORIG_RAX: 0000000000000010
 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7fda5115d7
 RDX: 000055b306db9188 RSI: 000000004008646e RDI: 0000000000000003
 RBP: 00007f7eec317ef0 R08: 00007f7eec318700 R09: 0000000000000000
 R10: 0000000000000000 R11: 0000000000000286 R12: 00007f7eec317fc0
 R13: 0000000000000000 R14: 0000000000000000 R15: 00007ffd8007ade0

 Allocated by task 2898:
  save_stack+0x32/0xb0
  kasan_kmalloc+0xa0/0xd0
  kmem_cache_alloc_trace+0x5e/0x180
  i915_ppgtt_create+0xab/0x2510
  i915_gem_create_context+0x981/0xf90
  i915_gem_context_create_ioctl+0x1d7/0x360
  drm_ioctl_kernel+0x1b0/0x2b0
  drm_ioctl+0x6fe/0xa20
  do_vfs_ioctl+0x189/0x12d0
  SyS_ioctl+0x6f/0x80
  do_syscall_64+0x214/0x5f0
  entry_SYSCALL_64_after_hwframe+0x3d/0xa2

 Freed by task 104:
  save_stack+0x32/0xb0
  kasan_slab_free+0x72/0xc0
  kfree+0x88/0x190
  i915_ppgtt_release+0x24e/0x460
  i915_gem_context_free+0x90/0x480
  contexts_free_worker+0x54/0x80
  process_one_work+0x876/0x14e0
  worker_thread+0x1b8/0xfd0
  kthread+0x2f8/0x3c0
  ret_from_fork+0x35/0x40

 The buggy address belongs to the object at ffff8881368a8000
  which belongs to the cache kmalloc-8192 of size 8192
 The buggy address is located 872 bytes inside of
  8192-byte region [ffff8881368a8000, ffff8881368aa000)
 The buggy address belongs to the page:
 page:ffffea0004da2a00 count:1 mapcount:0 mapping:          (null) index:0x0 compound_mapcount: 0
 flags: 0x200000000008100(slab|head)
 raw: 0200000000008100 0000000000000000 0000000000000000 0000000100030003
 raw: dead000000000100 dead000000000200 ffff88822a002280 0000000000000000
 page dumped because: kasan: bad access detected

 Memory state around the buggy address:
  ffff8881368a8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff8881368a8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 >ffff8881368a8300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                           ^
  ffff8881368a8380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff8881368a8400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ==================================================================

Fixes: 1acfc104cdf8 ("drm/i915: Enable rcu-only context lookups")
Reported-by: 罗权 
Cc: Chris Wilson 
Cc: Jon Bloomfield 
Cc: stable@vger.kernel.org # 4.14.x
Cc: stable@vger.kernel.org # 4.19.x
Signed-off-by: Tyler Hicks 
Signed-off-by: Greg Kroah-Hartman

drm/i915/gen9: Clear residual context state on context switch

2020-01-14T19:07:09+00:00

commit bc8a76a152c5f9ef3b48104154a65a68a8b76946 upstream.

Intel ID: PSIRT-TA-201910-001
CVEID: CVE-2019-14615

Intel GPU Hardware prior to Gen11 does not clear EU state
during a context switch. This can result in information
leakage between contexts.

For Gen8 and Gen9, hardware provides a mechanism for
fast cleardown of the EU state, by issuing a PIPE_CONTROL
with bit 27 set. We can use this in a context batch buffer
to explicitly cleardown the state on every context switch.

As this workaround is already in place for gen8, we can borrow
the code verbatim for Gen9.

Signed-off-by: Mika Kuoppala 
Signed-off-by: Akeem G Abodunrin 
Cc: Kumar Valsan Prathap 
Cc: Chris Wilson 
Cc: Balestrieri Francesco 
Cc: Bloomfield Jon 
Cc: Dutt Sudeep 
Signed-off-by: Greg Kroah-Hartman

drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ

2020-01-14T19:07:02+00:00

commit c4e4fccc5d52d881afaac11d3353265ef4eccb8b upstream.

[Why]
According to DP spec, it should shift left 4 digits for NO_STOP_BIT
in REMOTE_I2C_READ message. Not 5 digits.

In current code, NO_STOP_BIT is always set to zero which means I2C
master is always generating a I2C stop at the end of each I2C write
transaction while handling REMOTE_I2C_READ sideband message. This issue
might have the generated I2C signal not meeting the requirement. Take
random read in I2C for instance, I2C master should generate a repeat
start to start to read data after writing the read address. This issue
will cause the I2C master to generate a stop-start rather than a
re-start which is not expected in I2C random read.

[How]
Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case in
drm_dp_encode_sideband_req().

Changes since v1:(https://patchwork.kernel.org/patch/11312667/)
* Add more descriptions in commit and cc to stable

Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)")
Reviewed-by: Harry Wentland 
Signed-off-by: Wayne Lin 
Cc: stable@vger.kernel.org
Signed-off-by: Lyude Paul 
Link: https://patchwork.freedesktop.org/patch/msgid/20200103055001.10287-1-Wayne.Lin@amd.com
Signed-off-by: Greg Kroah-Hartman