kernel/linux.git/drivers/gpu/drm/etnaviv, branch v5.4.198

drm/etnaviv: check for reaped mapping in etnaviv_iommu_unmap_gem

2022-06-14T16:11:47+00:00

commit e168c25526cd0368af098095c2ded4a008007e1b upstream. When the mapping is already reaped the unmap must be a no-op, as we would otherwise try to remove the mapping twice, corrupting the involved data structures. Cc: stable@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach Reviewed-by: Philipp Zabel Tested-by: Guido Günther Acked-by: Guido Günther Signed-off-by: Greg Kroah-Hartman

drm/etnaviv: relax submit size limits

2022-02-01T16:24:34+00:00

commit e3d26528e083e612314d4dcd713f3d5a26143ddc upstream. While all userspace tried to limit commandstreams to 64K in size, a bug in the Mesa driver lead to command streams of up to 128K being submitted. Allow those to avoid breaking existing userspace. Fixes: 6dfa2fab8ddd ("drm/etnaviv: limit submit sizes") Cc: stable@vger.kernel.org Signed-off-by: Lucas Stach Reviewed-by: Christian Gmeiner Signed-off-by: Greg Kroah-Hartman

drm/etnaviv: limit submit sizes

2022-01-27T08:19:50+00:00

commit 6dfa2fab8ddd46faa771a102672176bee7a065de upstream. Currently we allow rediculous amounts of kernel memory being allocated via the etnaviv GEM_SUBMIT ioctl, which is a pretty easy DoS vector. Put some reasonable limits in to fix this. The commandstream size is limited to 64KB, which was already a soft limit on older kernels after which the kernel only took submits on a best effort base, so there is no userspace that tries to submit commandstreams larger than this. Even if the whole commandstream is a single incrementing address load, the size limit also limits the number of potential relocs and referenced buffers to slightly under 64K, so use the same limit for those arguments. The performance monitoring infrastructure currently supports less than 50 performance counter signals, so limiting them to 128 on a single submit seems like a reasonably future-proof number for now. This number can be bumped if needed without breaking the interface. Cc: stable@vger.kernel.org Reported-by: Dan Carpenter Signed-off-by: Lucas Stach Reviewed-by: Christian Gmeiner Signed-off-by: Greg Kroah-Hartman

drm/etnaviv: add missing MMU context put when reaping MMU mapping

2021-09-22T10:26:40+00:00

commit f2faea8b64125852fa9acc6771c07fc0311a039b upstream. When we forcefully evict a mapping from the the address space and thus the MMU context, the MMU context is leaked, as the mapping no longer points to it, so it doesn't get freed when the GEM object is destroyed. Add the mssing context put to fix the leak. Cc: stable@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach Tested-by: Michael Walle Tested-by: Marek Vasut Reviewed-by: Christian Gmeiner Signed-off-by: Greg Kroah-Hartman

drm/etnaviv: reference MMU context when setting up hardware state

2021-09-22T10:26:40+00:00

commit d6408538f091fb22d47f792d4efa58143d56c3fb upstream. Move the refcount manipulation of the MMU context to the point where the hardware state is programmed. At that point it is also known if a previous MMU state is still there, or the state needs to be reprogrammed with a potentially different context. Cc: stable@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach Tested-by: Michael Walle Tested-by: Marek Vasut Reviewed-by: Christian Gmeiner Signed-off-by: Greg Kroah-Hartman

drm/etnaviv: fix MMU context leak on GPU reset

2021-09-22T10:26:40+00:00

commit f978a5302f5566480c58ffae64a16d34456801bd upstream. After a reset the GPU is no longer using the MMU context and may be restarted with a different context. While the mmu_state proeprly was cleared, the context wasn't unreferenced, leading to a memory leak. Cc: stable@vger.kernel.org # 5.4 Reported-by: Michael Walle Signed-off-by: Lucas Stach Tested-by: Michael Walle Tested-by: Marek Vasut Reviewed-by: Christian Gmeiner Signed-off-by: Greg Kroah-Hartman

drm/etnaviv: exec and MMU state is lost when resetting the GPU

2021-09-22T10:26:40+00:00

commit 725cbc7884c37f3b4f1777bc1aea6432cded8ca5 upstream. When the GPU is reset both the current exec state, as well as all MMU state is lost. Move the driver side state tracking into the reset function to keep hardware and software state from diverging. Cc: stable@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach Tested-by: Michael Walle Tested-by: Marek Vasut Reviewed-by: Christian Gmeiner Signed-off-by: Greg Kroah-Hartman

drm/etnaviv: keep MMU context across runtime suspend/resume

2021-09-22T10:26:39+00:00

commit 8f3eea9d01d7b0f95b0fe04187c0059019ada85b upstream. The MMU state may be kept across a runtime suspend/resume cycle, as we avoid a full hardware reset to keep the latency of the runtime PM small. Don't pretend that the MMU state is lost in driver state. The MMU context is pushed out when new HW jobs with a different context are coming in. The only exception to this is when the GPU is unbound, in which case we need to make sure to also free the last active context. Cc: stable@vger.kernel.org # 5.4 Reported-by: Michael Walle Signed-off-by: Lucas Stach Tested-by: Michael Walle Tested-by: Marek Vasut Reviewed-by: Christian Gmeiner Signed-off-by: Greg Kroah-Hartman

drm/etnaviv: stop abusing mmu_context as FE running marker

2021-09-22T10:26:39+00:00

commit 23e0f5a57d0ecec86e1fc82194acd94aede21a46 upstream. While the DMA frontend can only be active when the MMU context is set, the reverse isn't necessarily true, as the frontend can be stopped while the MMU state is kept. Stop treating mmu_context being set as a indication that the frontend is running and instead add a explicit property. Cc: stable@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach Tested-by: Michael Walle Tested-by: Marek Vasut Reviewed-by: Christian Gmeiner Signed-off-by: Greg Kroah-Hartman

drm/etnaviv: put submit prev MMU context when it exists

2021-09-22T10:26:39+00:00

commit cda7532916f7bc860b36a1806cb8352e6f63dacb upstream. The prev context is the MMU context at the time of the job queueing in hardware. As a job might be queued multiple times due to recovery after a GPU hang, we need to make sure to put the stale prev MMU context from a prior queuing, to avoid the reference and thus the MMU context leaking. Cc: stable@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach Tested-by: Michael Walle Tested-by: Marek Vasut Reviewed-by: Christian Gmeiner Signed-off-by: Greg Kroah-Hartman