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 <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Pull bitmap updates from Yury Norov:
- introduce for_each_set_bitrange()
- use find_first_*_bit() instead of find_next_*_bit() where possible
- unify for_each_bit() macros
* tag 'bitmap-5.17-rc1' of git://github.com/norov/linux:
vsprintf: rework bitmap_list_string
lib: bitmap: add performance test for bitmap_print_to_pagebuf
bitmap: unify find_bit operations
mm/percpu: micro-optimize pcpu_is_populated()
Replace for_each_*_bit_from() with for_each_*_bit() where appropriate
find: micro-optimize for_each_{set,clear}_bit()
include/linux: move for_each_bit() macros from bitops.h to find.h
cpumask: replace cpumask_next_* with cpumask_first_* where appropriate
tools: sync tools/bitmap with mother linux
all: replace find_next{,_zero}_bit with find_first{,_zero}_bit where appropriate
cpumask: use find_first_and_bit()
lib: add find_first_and_bit()
arch: remove GENERIC_FIND_FIRST_BIT entirely
include: move find.h from asm_generic to linux
bitops: move find_bit_*_le functions from le.h to find.h
bitops: protect find_first_{,zero}_bit properly
A couple of kernel functions call for_each_*_bit_from() with start bit equal to 0. Replace them with for_each_*_bit(). No functional changes, but might improve on readability. Signed-off-by: Yury Norov <yury.norov@gmail.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
- make etnaviv work on IOMMU enabled systems - fix mapping of command buffers on systems with more than 4GB RAM - close a DoS vector - fix spurious GPU resets Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas Stach <l.stach@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/59619f8e9eb1d7ed7ea72cbead1f0aabc49f4e68.camel@pengutronix.de
Some GPU heavy test programs manage to trigger the hangcheck quite often. If there are no other GPU users in the system and the test program exhibits a very regular structure in the commandstreams that are being submitted, we can end up with two distinct submits managing to trigger the hangcheck with the FE in a very similar address range. This leads the hangcheck to believe that the GPU is stuck, while in reality the GPU is already busy working on a different job. To avoid those spurious GPU resets, also remember and consider the last completed fence seqno in the hang check. Reported-by: Joerg Albert <joerg.albert@iav.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
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 <dan.carpenter@oracle.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
The only usage of cooling_ops is to pass its address to thermal_of_cooling_device_register(), which takes a pointer to const struct thermal_cooling_device_ops as input. Make it const to allow the compiler to put it in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
The STLB and the first command buffer (which is used to set up the TLBs) has a 32 bit size restriction in hardware. There seems to be no way to specify addresses larger than 32 bit. Keep it simple and restict the addresses to the lower 4 GiB range for all coherent DMA memory allocations. Please note, that platform_device_alloc() will initialize dev->dma_mask to point to pdev->platform_dma_mask, thus dma_set_mask() will work as expected. While at it, move the dma_mask setup code to the of_dma_configure() to keep all the DMA setup code next to each other. Suggested-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
The DMA configuration of the virtual device is inherited from the first
actual etnaviv device. Unfortunately, this doesn't work with an IOMMU:
[ 5.191008] Failed to set up IOMMU for device (null); retaining platform DMA ops
This is because there is no associated iommu_group with the device. The
group is set in iommu_group_add_device() which is eventually called by
device_add() via the platform bus:
device_add()
blocking_notifier_call_chain()
iommu_bus_notifier()
iommu_probe_device()
__iommu_probe_device()
iommu_group_get_for_dev()
iommu_group_add_device()
Move of_dma_configure() into the probe function, which is called after
device_add(). Normally, the platform code will already call it itself
if .of_node is set. Unfortunately, this isn't the case here.
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
There is already a macro for the magic value. Use it. Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>