Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v4.12.12 2017-08-16T20:46:53+00:00 2017-08-16T20:46:53+00:00 Wladimir J. van der Laan laanwj@gmail.com 2017-07-25T12:33:36+00:00 urn:sha1:4eedc8a7f03b15a9daad69b4d54e43f79fa0e16e 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 <laanwj@gmail.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-27T22:10:14+00:00 Eric Anholt eric@anholt.net 2017-04-11T01:44:13+00:00 urn:sha1:719829d19c0ce215ff9b4f0b76c845bfa8cca64d commit 8555137e26618490cbeb12c243818539875d12f4 upstream. 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 <eric@anholt.net> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: etnaviv@lists.freedesktop.org Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-06-28T20:13:48+00:00 Linus Torvalds torvalds@linux-foundation.org 2017-06-28T20:13:48+00:00 urn:sha1:cf723497f2b0dfd688dd27949f1d6e26a5aec44c Pull drm/etnaviv fixes from Lucas Stach: "I realized I just missed the cut-off point for the final drm fixes pull, but I have 2 more etnaviv fixes that need to go into 4.12, as they fix fallout from the explicit sync work introduced in the last merge window" [ Pulling directly because Dave is on vacation. Noted by Daniel Vetter, and acked by Dave Airlie - Linus ] * 'etnaviv/fixes' of git://git.pengutronix.de/git/lst/linux: drm/etnaviv: Fix implicit/explicit sync sense inversion drm/etnaviv: fix submit flags getting overwritten by BO content 2017-06-28T08:35:53+00:00 Daniel Stone daniels@collabora.com 2017-06-22T11:22:22+00:00 urn:sha1:426ef1bb40a3bd99ccd16d629bd1294805e96fc6 We were reading the no-implicit sync flag the wrong way around, synchronizing too much for the explicit case, and not at all for the implicit case. Oops. Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> 2017-06-28T08:35:46+00:00 Lucas Stach l.stach@pengutronix.de 2017-06-27T14:02:51+00:00 urn:sha1:f4a4381ba4944603905167d044d865990356ba22 The addition of the flags member to etnaviv_gem_submit structure didn't take into account that the last member of this structure is a variable length array. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> 2017-05-19T00:16:06+00:00 Dave Airlie airlied@redhat.com 2017-05-19T00:16:06+00:00 urn:sha1:389cf7080c062eb5fae525858d2e70aea0422d89 one etnaviv fence leak fix. * 'etnaviv/fixes' of https://git.pengutronix.de/git/lst/linux: drm/etnaviv: don't put fence in case of submit failure 2017-05-09T00:15:13+00:00 Michal Hocko mhocko@suse.com 2017-05-08T22:57:44+00:00 urn:sha1:19809c2da28aee5860ad9a2eff760730a0710df0 __vmalloc* allows users to provide gfp flags for the underlying allocation. This API is quite popular $ git grep "=[[:space:]]__vmalloc\|return[[:space:]]*__vmalloc" | wc -l 77 The only problem is that many people are not aware that they really want to give __GFP_HIGHMEM along with other flags because there is really no reason to consume precious lowmemory on CONFIG_HIGHMEM systems for pages which are mapped to the kernel vmalloc space. About half of users don't use this flag, though. This signals that we make the API unnecessarily too complex. This patch simply uses __GFP_HIGHMEM implicitly when allocating pages to be mapped to the vmalloc space. Current users which add __GFP_HIGHMEM are simplified and drop the flag. Link: http://lkml.kernel.org/r/20170307141020.29107-1-mhocko@kernel.org Signed-off-by: Michal Hocko <mhocko@suse.com> Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: David Rientjes <rientjes@google.com> Cc: Cristopher Lameter <cl@linux.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2017-05-05T15:12:34+00:00 Lucas Stach l.stach@pengutronix.de 2017-04-28T15:30:52+00:00 urn:sha1:657314b7a5d16961e7e0ecdae4a59d28123e74c0 If we bail out of the submit before actually adding the cmdstream to the kernel ring there is no valid fence to put. Make sure to skip the fence_put in that case. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> 2017-04-19T01:07:14+00:00 Dave Airlie airlied@redhat.com 2017-04-19T01:07:14+00:00 urn:sha1:856ee92e8602bd86d34388ac08381c5cb3918756 Backmerge Linux 4.11-rc7 from Linus tree, to fix some conflicts that were causing problems with the rerere cache in drm-tip. 2017-04-12T15:22:05+00:00 Wei Yongjun weiyongjun1@huawei.com 2017-04-12T00:31:16+00:00 urn:sha1:45abdf35cf82e4270328c7237e7812de960ac560 Add the missing unlock before return from function etnaviv_gpu_submit() in the error handling case. lst: fixed label name. Fixes: f3cd1b064f11 ("drm/etnaviv: (re-)protect fence allocation with GPU mutex") CC: stable@vger.kernel.org #4.9+ Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>