kernel/drivers/gpu/drm/msm, branch linux-4.1.y

drm/msm: fix leak in failed get_pages

2018-05-23T01:33:51Z

[ Upstream commit 62e3a3e342af3c313ab38603811ecdb1fcc79edb ] get_pages doesn't keep a reference of the pages allocated when it fails later in the code path. This can lead to a memory leak. Keep reference of the allocated pages so that it can be freed when msm_gem_free_object gets called later during cleanup. Signed-off-by: Prakash Kamliya Signed-off-by: Sharat Masetty Signed-off-by: Rob Clark Signed-off-by: Sasha Levin

drm/msm: fix an integer overflow test

2017-12-07T02:19:54Z

[ Upstream commit 65e93108891e571f177c202add9288eda9ac4100 ] We recently added an integer overflow check but it needs an additional tweak to work properly on 32 bit systems. The problem is that we're doing the right hand side of the assignment as type unsigned long so the max it will have an integer overflow instead of being larger than SIZE_MAX. That means the "sz > SIZE_MAX" condition is never true even on 32 bit systems. We need to first cast it to u64 and then do the math. Fixes: 4a630fadbb29 ("drm/msm: Fix potential buffer overflow issue") Signed-off-by: Dan Carpenter Acked-by: Jordan Crouse Signed-off-by: Rob Clark Signed-off-by: Sasha Levin

drm/msm: Fix potential buffer overflow issue

2017-12-07T02:19:54Z

[ Upstream commit 4a630fadbb29d9efaedb525f1a8f7449ad107641 ] In function submit_create, if nr_cmds or nr_bos is assigned with negative value, the allocated buffer may be small than intended. Using this buffer will lead to buffer overflow issue. Signed-off-by: Kasin Li Signed-off-by: Jordan Crouse Signed-off-by: Rob Clark Signed-off-by: Sasha Levin

drm/msm: Verify that MSM_SUBMIT_BO_FLAGS are set

2017-09-10T20:35:54Z

[ 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

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

2017-09-10T20:35:53Z

[ 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

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

2017-06-08T10:42:00Z

[ 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/msm: fix use of copy_from_user() while holding spinlock

2016-12-22T03:45:42Z

[ Upstream commit 89f82cbb0d5c0ab768c8d02914188aa2211cd2e3 ] Use instead __copy_from_user_inatomic() and fallback to slow-path where we drop and re-aquire the lock in case of fault. Cc: stable@vger.kernel.org Reported-by: Vaishali Thakkar Signed-off-by: Rob Clark Signed-off-by: Sasha Levin

drm/msm/mdp5: fix incorrect parameter for msm_framebuffer_iova()

2015-05-21T04:31:45Z

The index of ->planes[] array (3rd parameter) cannot be equal to MAX_PLANE. This looks like a typo that is now fixed. Signed-off-by: Stephane Viau Acked-by: Rob Clark Signed-off-by: Dave Airlie

drm/msm: fix locking inconsistencies in gpu->destroy()

2015-05-15T13:28:27Z

In error paths, this was being called without struct_mutex held. Leading to panics like: msm 1a00000.qcom,mdss_mdp: No memory protection without IOMMU Kernel panic - not syncing: BUG! CPU: 0 PID: 1409 Comm: cat Not tainted 4.0.0-dirty #4 Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) Call trace: [] dump_backtrace+0x0/0x118 [] show_stack+0x10/0x20 [] dump_stack+0x84/0xc4 [] panic+0xd0/0x210 [] drm_gem_object_free+0x5c/0x60 [] adreno_gpu_cleanup+0x60/0x80 [] a3xx_destroy+0x20/0x70 [] a3xx_gpu_init+0x84/0x108 [] adreno_load_gpu+0x58/0x190 [] msm_open+0x74/0x88 [] drm_open+0x168/0x400 [] drm_stub_open+0xa8/0x118 [] chrdev_open+0x94/0x198 [] do_dentry_open+0x208/0x310 [] vfs_open+0x44/0x50 [] do_last.isra.14+0x2c4/0xc10 [] path_openat+0x80/0x5e8 [] do_filp_open+0x2c/0x98 [] do_sys_open+0x13c/0x228 [] SyS_openat+0xc/0x18 CPU1: stopping But there isn't any particularly good reason to hold struct_mutex for teardown, so just standardize on calling it without the mutex held and use the _unlocked() versions for GEM obj unref'ing Signed-off-by: Rob Clark

drm/msm/dsi: Simplify the code to get the number of read byte

2015-05-14T20:57:25Z

During cmd rx, only new versions of H/W provide register to read back the real number of byte returned by panel. For the old versions, reading this register will not get the right number. In fact, we only need to assume the returned data is the same size as we expected, because later we will check the data type to detect error. Signed-off-by: Hai Li