Linaro-mm-sig February 2024

linaro-mm-sig@lists.linaro.org

17 participants
43 discussions

Re: [PATCH 06/11] drm/mediatek: Rename files "mtk_drm_crtc.*" to "mtk_crtc.*"

by AngeloGioacchino Del Regno

Il 26/02/24 09:50, Shawn Sung ha scritto: > From: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> > > Rename files mtk_drm_crtc.* to mtk_crtc.*. > > Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> Reviewed-by: AngeloGiaocchino Del Regno <angelogioacchino.delregno(a)collabora.com>

2 months, 1 week

Re: [PATCH 07/11] drm/mediatek: Rename files "mtk_drm_ddp_comp.*" to "mtk_ddp_comp.*"

by AngeloGioacchino Del Regno

Il 26/02/24 09:50, Shawn Sung ha scritto: > From: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> > > Rename files mtk_drm_ddp_comp.* to mtk_ddp_comp.*. > > Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> Reviewed-by: AngeloGiaocchino Del Regno <angelogioacchino.delregno(a)collabora.com>

2 months, 1 week

Re: [PATCH 08/11] drm/mediatek: Rename files "mtk_drm_plane.*" to "mtk_plane.*"

by AngeloGioacchino Del Regno

Il 26/02/24 09:50, Shawn Sung ha scritto: > From: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> > > Rename files mtk_drm_plane.* to mtk_plane.*. > > Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> Reviewed-by: AngeloGiaocchino Del Regno <angelogioacchino.delregno(a)collabora.com>

2 months, 1 week

Re: [PATCH 09/11] drm/mediatek: Rename files "mtk_drm_gem.*" to "mtk_gem.*"

by AngeloGioacchino Del Regno

Il 26/02/24 09:50, Shawn Sung ha scritto: > From: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> > > Rename files mtk_drm_gem.* to mtk_gem.*. > > Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> Reviewed-by: AngeloGiaocchino Del Regno <angelogioacchino.delregno(a)collabora.com>

2 months, 1 week

Re: [PATCH 10/11] drm/mediatek: Rename mtk_ddp_comp functions

by AngeloGioacchino Del Regno

Il 26/02/24 09:50, Shawn Sung ha scritto: > From: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> > > Rename functions of mtk_ddp_comp: > - To align the naming rule > - To reduce the code size > > Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> Reviewed-by: AngeloGiaocchino Del Regno <angelogioacchino.delregno(a)collabora.com>

2 months, 1 week

Re: [PATCH v5] drm/test: add a test suite for GEM objects backed by shmem

by Guenter Roeck

On Thu, Feb 22, 2024 at 05:33:48PM +0100, Marco Pagani wrote: > > > > In this context, the TTM unit tests fail as well in qemu, with worse result: > > It seems there is some bad cleanup after a failed test case, causing list > > corruptions in the drm core and ultimately a crash. I don't know if this > > is also caused by the missing dma_mask initialization. > > > > That's interesting. Which --arch argument are you using to run the > tests with QEMU? Example (I am not sure if any of those parameters matters; it is just one of my tests): qemu-system-x86_64 -kernel arch/x86/boot/bzImage -M q35 -cpu IvyBridge \ -no-reboot -snapshot -smp 2 \ -device e1000,netdev=net0 -netdev user,id=net0 -m 512 \ -drive file=rootfs.ext2,format=raw,if=ide \ --append "earlycon=uart8250,io,0x3f8,9600n8 root=/dev/sda1 console=ttyS0" \ -d unimp,guest_errors -nographic -monitor none This results in: [ ... ] [ 5.989496] KTAP version 1 [ 5.989639] # Subtest: ttm_device [ 5.989711] # module: ttm_device_test [ 5.989760] 1..5 [ 6.002044] ok 1 ttm_device_init_basic [ 6.013557] ok 2 ttm_device_init_multiple ILLOPC: ffffffffb8ac9350: 0f 0b [ 6.022481] ok 3 ttm_device_fini_basic [ 6.026172] ------------[ cut here ]------------ [ 6.026315] WARNING: CPU: 1 PID: 1575 at drivers/gpu/drm/ttm/ttm_device.c:206 ttm_device_init+0x170/0x190 ... [ 6.135016] ok 3 Above the allocation limit [ 6.138759] ------------[ cut here ]------------ [ 6.138925] WARNING: CPU: 1 PID: 1595 at kernel/dma/mapping.c:503 dma_alloc_attrs+0xf6/0x100 ... [ 6.143850] # ttm_pool_alloc_basic: ASSERTION FAILED at drivers/gpu/drm/ttm/tests/ttm_pool_test.c:162 [ 6.143850] Expected err == 0, but [ 6.143850] err == -12 (0xfffffffffffffff4) [ 6.148824] not ok 4 One page, with coherent DMA mappings enabled From there things go downhill. [ 6.152821] list_add corruption. prev->next should be next (ffffffffbbd53950), but was 0000000000000000. (prev=ffff8af1c38f9e20). and so on until the emulation crashes. Guenter

2 months, 2 weeks

Re: [PATCH v5] drm/test: add a test suite for GEM objects backed by shmem

by Guenter Roeck

Hi Marco, On 2/22/24 07:32, Marco Pagani wrote: > > > On 2024-02-18 16:49, Guenter Roeck wrote: >> Hi, >> >> On Thu, Nov 30, 2023 at 06:14:16PM +0100, Marco Pagani wrote: >>> This patch introduces an initial KUnit test suite for GEM objects >>> backed by shmem buffers. >>> >>> Suggested-by: Javier Martinez Canillas <javierm(a)redhat.com> >>> Signed-off-by: Marco Pagani <marpagan(a)redhat.com> >> >> When running this in qemu, I get lots of warnings backtraces in the drm >> core. >> >> WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:327 >> WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:173 >> WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:385 >> WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:211 >> WARNING: CPU: 0 PID: 1345 at kernel/dma/mapping.c:194 >> WARNING: CPU: 0 PID: 1347 at drivers/gpu/drm/drm_gem_shmem_helper.c:429 >> WARNING: CPU: 0 PID: 1349 at drivers/gpu/drm/drm_gem_shmem_helper.c:445 >> >> It looks like dma_resv_assert_held() asserts each time it is executed. >> The backtrace in kernel/dma/mapping.c is triggered by >> if (WARN_ON_ONCE(!dev->dma_mask)) >> return 0; >> in __dma_map_sg_attrs(). >> >> Is this a possible problem in the test code, or can it be caused by >> some limitations or bugs in the qemu emulation ? If so, do you have any >> thoughts or ideas what those limitations / bugs might be ? > > Hi Guenter, > > Thanks for reporting this issue. As you correctly noted, the warnings appear to > be caused by the dma_mask in the mock device being uninitialized. I'll send a > patch to fix it soon. > Thanks a lot for the update. In this context, the TTM unit tests fail as well in qemu, with worse result: It seems there is some bad cleanup after a failed test case, causing list corruptions in the drm core and ultimately a crash. I don't know if this is also caused by the missing dma_mask initialization. Thanks, Guenter

2 months, 2 weeks

[PATCH v2] udmabuf: Fix a potential (and unlikely) access to unallocated memory

by Christophe JAILLET

If 'list_limit' is set to a very high value, 'lsize' computation could overflow if 'head.count' is big enough. In such a case, udmabuf_create() would access to memory beyond 'list'. Use memdup_array_user() which checks for overflow. While at it, include <linux/string.h>. Fixes: fbb0de795078 ("Add udmabuf misc device") Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> --- v2: - Use memdup_array_user() [Kees Cook] - Use sizeof(*list) [Gustavo A. R. Silva] - Add include <linux/string.h> v1: https://lore.kernel.org/all/3e37f05c7593f1016f0a46de188b3357cbbd0c0b.169506… Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> --- drivers/dma-buf/udmabuf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index c40645999648..5728948ea6f2 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -11,6 +11,7 @@ #include <linux/module.h> #include <linux/shmem_fs.h> #include <linux/slab.h> +#include <linux/string.h> #include <linux/udmabuf.h> #include <linux/vmalloc.h> #include <linux/iosys-map.h> @@ -314,14 +315,13 @@ static long udmabuf_ioctl_create_list(struct file *filp, unsigned long arg) struct udmabuf_create_list head; struct udmabuf_create_item *list; int ret = -EINVAL; - u32 lsize; if (copy_from_user(&head, (void __user *)arg, sizeof(head))) return -EFAULT; if (head.count > list_limit) return -EINVAL; - lsize = sizeof(struct udmabuf_create_item) * head.count; - list = memdup_user((void __user *)(arg + sizeof(head)), lsize); + list = memdup_array_user((void __user *)(arg + sizeof(head)), + sizeof(*list), head.count); if (IS_ERR(list)) return PTR_ERR(list); -- 2.43.2

2 months, 2 weeks

Re: [PATCH v5] drm/test: add a test suite for GEM objects backed by shmem

by Guenter Roeck

Hi, On Thu, Nov 30, 2023 at 06:14:16PM +0100, Marco Pagani wrote: > This patch introduces an initial KUnit test suite for GEM objects > backed by shmem buffers. > > Suggested-by: Javier Martinez Canillas <javierm(a)redhat.com> > Signed-off-by: Marco Pagani <marpagan(a)redhat.com> When running this in qemu, I get lots of warnings backtraces in the drm core. WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:327 WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:173 WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:385 WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:211 WARNING: CPU: 0 PID: 1345 at kernel/dma/mapping.c:194 WARNING: CPU: 0 PID: 1347 at drivers/gpu/drm/drm_gem_shmem_helper.c:429 WARNING: CPU: 0 PID: 1349 at drivers/gpu/drm/drm_gem_shmem_helper.c:445 It looks like dma_resv_assert_held() asserts each time it is executed. The backtrace in kernel/dma/mapping.c is triggered by if (WARN_ON_ONCE(!dev->dma_mask)) return 0; in __dma_map_sg_attrs(). Is this a possible problem in the test code, or can it be caused by some limitations or bugs in the qemu emulation ? If so, do you have any thoughts or ideas what those limitations / bugs might be ? Thanks, Guenter

2 months, 2 weeks

[PATCH] dma-buf: try to catch swiotlb bounce buffers

by Daniel Vetter

They rather fundamentally break the entire concept of zero copy, so if an exporter manages to hand these out things will break all over. Luckily there's not too many case that use swiotlb_sync_single_for_device/cpu(): - The generic iommu dma-api code in drivers/iommu/dma-iommu.c. We can catch that with sg_dma_is_swiotlb() reliably. - The generic direct dma code in kernel/dma/direct.c. We can mostly catch that with looking for a NULL dma_ops, except for some powerpc special cases. - Xen, which I don't bother to catch here. Implement these checks in dma_buf_map_attachment when CONFIG_DMA_API_DEBUG is enabled. Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: Paul Cercueil <paul(a)crapouillou.net> --- Entirely untested, but since I sent the mail with the idea I figured I might as well type it up after I realized there's a lot fewer cases to check. That is, if I haven't completely misread the dma-api and swiotlb code. -Sima --- drivers/dma-buf/dma-buf.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d1e7f823fbdb..d6f95523f995 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -28,6 +28,12 @@ #include <linux/mount.h> #include <linux/pseudo_fs.h> +#ifdef CONFIG_DMA_API_DEBUG +#include <linux/dma-direct.h> +#include <linux/dma-map-ops.h> +#include <linux/swiotlb.h> +#endif + #include <uapi/linux/dma-buf.h> #include <uapi/linux/magic.h> @@ -1149,10 +1155,13 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, #ifdef CONFIG_DMA_API_DEBUG if (!IS_ERR(sg_table)) { struct scatterlist *sg; + struct device *dev = attach->dev; u64 addr; int len; int i; + bool is_direct_dma = !get_dma_ops(dev); + for_each_sgtable_dma_sg(sg_table, sg, i) { addr = sg_dma_address(sg); len = sg_dma_len(sg); @@ -1160,7 +1169,15 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, pr_debug("%s: addr %llx or len %x is not page aligned!\n", __func__, addr, len); } + + if (is_direct_dma) { + phys_addr_t paddr = dma_to_phys(dev, addr); + + WARN_ON_ONCE(is_swiotlb_buffer(dev, paddr)); + } } + + WARN_ON_ONCE(sg_dma_is_swiotlb(sg)); } #endif /* CONFIG_DMA_API_DEBUG */ return sg_table; -- 2.43.0

3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig February 2024