Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

14 participants
3704 discussions

[PATCH v2] dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning

by Mikhail Gavrilov

When CONFIG_DMA_API_DEBUG_SG is enabled, importing a udmabuf into a DRM driver (e.g. amdgpu for video playback in GNOME Videos / Showtime) triggers a spurious warning: DMA-API: amdgpu 0000:03:00.0: cacheline tracking EEXIST, \ overlapping mappings aren't supported WARNING: kernel/dma/debug.c:619 at add_dma_entry+0x473/0x5f0 The call chain is: amdgpu_cs_ioctl -> amdgpu_ttm_backend_bind -> dma_buf_map_attachment -> [udmabuf] map_udmabuf -> get_sg_table -> dma_map_sgtable(dev, sg, direction, 0) // attrs=0 -> debug_dma_map_sg -> add_dma_entry -> EEXIST This happens because udmabuf builds a per-page scatter-gather list via sg_set_folio(). When begin_cpu_udmabuf() has already created an sg table mapped for the misc device, and an importer such as amdgpu maps the same pages for its own device via map_udmabuf(), the DMA debug infrastructure sees two active mappings whose physical addresses share cacheline boundaries and warns about the overlap. The DMA_ATTR_SKIP_CPU_SYNC flag suppresses this check in add_dma_entry() because it signals that no CPU cache maintenance is performed at map/unmap time, making the cacheline overlap harmless. All other major dma-buf exporters already pass this flag: - drm_gem_map_dma_buf() passes DMA_ATTR_SKIP_CPU_SYNC - amdgpu_dma_buf_map() passes DMA_ATTR_SKIP_CPU_SYNC The CPU sync at map/unmap time is also redundant for udmabuf: begin_cpu_udmabuf() and end_cpu_udmabuf() already perform explicit cache synchronization via dma_sync_sgtable_for_cpu/device() when CPU access is requested through the dma-buf interface. Pass DMA_ATTR_SKIP_CPU_SYNC to dma_map_sgtable() and dma_unmap_sgtable() in udmabuf to suppress the spurious warning and skip the redundant sync. Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access hooks") Cc: stable(a)vger.kernel.org Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov(a)gmail.com> --- v1 -> v2: - Rebased on drm-tip to resolve conflict with folio conversion patches. No code change, same two-line fix. v1: https://lore.kernel.org/all/20260317053653.28888-1-mikhail.v.gavrilov@gmail… drivers/dma-buf/udmabuf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index 94b26ea706a3..bced421c0d65 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -145,7 +145,7 @@ static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, if (ret < 0) goto err_alloc; - ret = dma_map_sgtable(dev, sg, direction, 0); + ret = dma_map_sgtable(dev, sg, direction, DMA_ATTR_SKIP_CPU_SYNC); if (ret < 0) goto err_map; return sg; @@ -160,7 +160,7 @@ static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, static void put_sg_table(struct device *dev, struct sg_table *sg, enum dma_data_direction direction) { - dma_unmap_sgtable(dev, sg, direction, 0); + dma_unmap_sgtable(dev, sg, direction, DMA_ATTR_SKIP_CPU_SYNC); sg_free_table(sg); kfree(sg); } -- 2.53.0

6 months, 1 week

[PATCH v13 0/5] Rust bindings for gem shmem

by Lyude Paul

Most of this patch series has already been pushed upstream, this is just the second half of the patch series that has not been pushed yet + some additional changes which were required to implement changes requested by the mailing list. This patch series is originally from Asahi, previously posted by Daniel Almeida. The previous version of the patch series can be found here: https://patchwork.freedesktop.org/series/164580/ Branch with patches applied available here sure this builds: https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem This patch series applies on top of drm-rust-next Lyude Paul (5): rust: drm: gem: s/device::Device/Device/ for shmem.rs drm/gem/shmem: Introduce __drm_gem_shmem_free_sgt_locked() rust: drm: gem/shmem: Add DmaResvGuard helper rust: drm: gem: Introduce shmem::SGTable rust: drm: gem: Add vmap functions to shmem bindings drivers/gpu/drm/drm_gem_shmem_helper.c | 32 +- include/drm/drm_gem_shmem_helper.h | 1 + rust/kernel/drm/gem/shmem.rs | 602 ++++++++++++++++++++++++- 3 files changed, 614 insertions(+), 21 deletions(-) base-commit: d9a6809478f9815b6455a327aa001737ac7b2c09 -- 2.54.0

6 months, 1 week

[PATCH RFC 0/3] media: videobuf2: opt-in dma_resv producer fences for V4L2 dmabuf exports

by Markus Fritsche

Hi, This series proposes a small opt-in API in videobuf2-core that lets V4L2 drivers populate a dma_resv exclusive write fence on the dmabufs they export to userspace, signalled when the buffer transitions to VB2_BUF_STATE_DONE. Two example drivers (hantro, rockchip-rga) opt in to demonstrate the call shape; the change is no-op for every other driver. Why --- Modern Wayland compositors and any other userspace consumers that import V4L2-produced dmabufs and want to do implicit synchronization the spec-clean way (poll(POLLIN) on the dmabuf fd, or DMA_BUF_IOCTL_EXPORT_SYNC_FILE for a sync_file) currently get either: 1. A stub fence from dma_buf_export_sync_file(), because the dmabuf's dma_resv has no fences populated. The kernel substitutes dma_fence_get_stub() which is permanently signalled. The compositor "successfully" waits on a fence that represents nothing real about the producer's state. 2. A poll(POLLIN) on the dmabuf fd that returns immediately for the same reason — dma_buf_poll_add_cb finds zero fences in the resv, triggers the wake callback inline, and reports POLLIN ready before the producer has actually said anything. Today this works as a happy accident on most paths because clients attach buffers after VIDIOC_DQBUF, which the userspace V4L2 contract guarantees only returns a buffer after the producer is done. So the implicit "the kernel's stub fence is fine because the buffer is already complete by the time anyone polls it" assumption has held. But: - It's a contract gap. The kernel claims to expose implicit sync; it does not, for V4L2 producers. - It paid latency for nothing. Every Wayland frame from a V4L2 producer pays a DMA_BUF_IOCTL_EXPORT_SYNC_FILE round-trip for a fence that's stub-signalled. On Mali-class hardware (RK3566 Wayland chrome video playback), this contributed to compositor stalls. Removing the wait at the compositor level is a workaround, not a fix. - It blocks downstream consumers from doing the right thing. A Wayland compositor that defensively waits on a sync_file gets a stub-fence pass-through with no actual gating; if the V4L2 driver ever has an out-of-band path that releases the buffer before finishing the write, there is no fence to gate on. What ---- Patch 1 adds: - struct dma_fence *release_fence to struct vb2_buffer - u64 dma_resv_fence_context + atomic64_t dma_resv_fence_seqno + spinlock_t dma_resv_fence_lock to struct vb2_queue - vb2_buffer_attach_release_fence(vb) — drivers call this from their buf_queue callback. Allocates a dma_fence on the queue's fence context, attaches it as DMA_RESV_USAGE_WRITE on each plane's dmabuf->resv. No-op for buffers without exported dmabufs. - vb2_buffer_done() extended to signal+put the fence if attached, so the producer's completion signal lands in the resv synchronously with the userspace DQBUF wakeup. Patches 2 and 3 add a single call to the helper from hantro_buf_queue and rga_buf_queue respectively. Both are demonstration drivers; other vb2 drivers can opt in incrementally with the same one-line change. Tested on --------- PineTab2 (RK3566 / Mali-G52 panfrost / mainline 6.19.10, this series backported), playing 1080p30 H.264 in chromium under KDE Plasma 6.6.4 Wayland. The test harness is the chromium-fourier patch series at https://github.com/marfrit/fourier — chromium plus a KWin patch that *previously bypassed* Transaction::watchDmaBuf because the kernel-side fence was stub-signalled. With this series applied, the bypass becomes unnecessary; KWin's fence wait completes correctly because the fence now signals when hantro completes the capture buffer write. End-to-end result before the kernel patch (chromium + Qt 6 patches + KWin watchDmaBuf bypass): 1080p30 H.264 plays through, ~81% combined chrome CPU, but the watchDmaBuf bypass weakens KWin's defenses against misbehaving clients. End-to-end result after the kernel patch (chromium + Qt 6 patches + plain unmodified KWin): 1080p30 H.264 plays through with the same CPU profile, KWin's watchDmaBuf wait completes within microseconds against the now-real producer fence, no defenses weakened. What's missing in this RFC -------------------------- - Other vb2-using drivers don't opt in. Each maintainer should look at their driver and decide. The hantro + rga patches show the shape; copying it to other drivers should be straightforward. - For drivers that have intermediate image-processor stages (e.g. CSI -> ISP -> user), the fence semantics across stage boundaries are out of scope here. This series only addresses the producer-to- userspace edge. - No selftest. videobuf2 doesn't have a great in-tree selftest harness for dmabuf flows; the validation is end-to-end at the userspace consumer level (KWin, in our case). Reviews especially welcome on: - The decision to make this opt-in per driver vs. automatic for all vb2-CAPTURE queues. Auto-on would force every driver to be audited; opt-in is incremental and safer but leaves the contract gap for drivers nobody touches. - Whether vb2_buffer_done is the right place to signal vs. an earlier hook (e.g. immediately after DMA-from-device finishes). For hantro the two are effectively the same; for drivers with asynchronous post-processing they may differ. - The choice of DMA_RESV_USAGE_WRITE — we are emitting the producer's write completion, so WRITE matches dma-buf documentation, but a sanity check is welcome. Cheers, Markus Markus Fritsche (3): media: videobuf2: add dma_resv release-fence helper media: hantro: attach dma_resv release fence at buf_queue media: rockchip-rga: attach dma_resv release fence at buf_queue .../media/common/videobuf2/videobuf2-core.c | 95 +++++++++++++++++++ drivers/media/platform/rockchip/rga/rga-buf.c | 10 ++ .../media/platform/verisilicon/hantro_v4l2.c | 12 +++ include/media/videobuf2-core.h | 29 ++++++ 4 files changed, 146 insertions(+) -- 2.47.3

6 months, 1 week

[PATCH v2] dma-buf: heaps: use max3() in dma_heap_ioctl

by Thorsten Blum

Replace two nested max() calls with a single max3() in dma_heap_ioctl(). Reviewed-by: T.J. Mercier <tjmercier(a)google.com> Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- Changes in v2: - Include minmax.h as suggested by T.J. Mercier - v1: https://lore.kernel.org/lkml/20260427172519.417333-3-thorsten.blum@linux.de… --- drivers/dma-buf/dma-heap.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c index ac5f8685a649..d49188893608 100644 --- a/drivers/dma-buf/dma-heap.c +++ b/drivers/dma-buf/dma-heap.c @@ -13,6 +13,7 @@ #include <linux/err.h> #include <linux/export.h> #include <linux/list.h> +#include <linux/minmax.h> #include <linux/nospec.h> #include <linux/syscalls.h> #include <linux/uaccess.h> @@ -153,7 +154,7 @@ static long dma_heap_ioctl(struct file *file, unsigned int ucmd, in_size = 0; if ((ucmd & kcmd & IOC_OUT) == 0) out_size = 0; - ksize = max(max(in_size, out_size), drv_size); + ksize = max3(in_size, out_size, drv_size); /* If necessary, allocate buffer for ioctl argument */ if (ksize > sizeof(stack_kdata)) {

6 months, 2 weeks

[PATCH] dma-buf: heaps: use max3() in dma_heap_ioctl

by Thorsten Blum

Replace two nested max() calls with a single max3() in dma_heap_ioctl(). Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- drivers/dma-buf/dma-heap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c index ac5f8685a649..52eec2ebb2e8 100644 --- a/drivers/dma-buf/dma-heap.c +++ b/drivers/dma-buf/dma-heap.c @@ -153,7 +153,7 @@ static long dma_heap_ioctl(struct file *file, unsigned int ucmd, in_size = 0; if ((ucmd & kcmd & IOC_OUT) == 0) out_size = 0; - ksize = max(max(in_size, out_size), drv_size); + ksize = max3(in_size, out_size, drv_size); /* If necessary, allocate buffer for ioctl argument */ if (ksize > sizeof(stack_kdata)) {

6 months, 2 weeks

[PATCH V13 0/7] Rust support for powerpc

by Mukesh Kumar Chaurasiya (IBM)

Enable experimental rust support for ppc64le and ppc32be. The patch for ppc32 has been provided by Link Mauve[1] and ppc64le support[2] has been merged over it. ppc32 needs some toolchain fixes mentioned in the patch `rust: Add PowerPC support` and the discussion for that is done here[1]. This has been tested on - powernv9 hardware - pseries P11 hardware - pseries(9, 10) qemu - powernv(9, 10) qemu - rustdoc on x86 and powerpc64le - rusttest on x86 and powerpc64le We are actively working with our LLVM team to get the target for ppc, ppc64 and ppc64le in the rust compiler. [1] https://lore.kernel.org/all/20260204030507.8203-1-linkmauve@linkmauve.fr [2] https://lore.kernel.org/all/20260204042417.83903-1-mkchauras@gmail.com Changelog: V12 -> V13: - Added a patch for fixing build issue on ppc32 by Link Mauve - Added another patch to fix a build issue in dma-buf - Added another patch to enforce minimum `rustc` version for powerpc V12: https://lore.kernel.org/all/20260421120958.190430-1-mkchauras@gmail.com/ V11 -> V12: - Rebased to mainline (rust/Makefile conflict resolved) V11: https://lore.kernel.org/all/20260417152253.2312961-1-mkchauras@gmail.com/ V10 -> V11: - Updated `rust/Makefile` - Not all libraries are move to `rust/host` directory now. Only proc_macro2, quote and syn are moved - Special handling for pin init is added. Details in commit - Removed mkdir for `rust/host`, this is now handled by toolchain. V10: https://lore.kernel.org/all/20260406200149.3727922-1-mkchauras@gmail.com/ V9 -> V10: - rust/Makefile updated with review comments from Miguel - Patch 1/4 updated with commit message and subject V9: https://lore.kernel.org/all/20260404121610.1956528-1-mkchauras@gmail.com/ V8 -> V9: - rust/Makefile updated with a directory instead of abspath V8: https://lore.kernel.org/all/20260403145308.1042622-1-mkchauras@gmail.com/ V7 -> V8: - rust/Makefile updated to separate host libraries from target V7: https://lore.kernel.org/all/20260329160254.2592207-1-mkchauras@gmail.com/ Changelog: V6 -> V7: - Documentation removed as powerpc is still under development - Added a fix for race condition in rust/Makefile V6: https://lore.kernel.org/all/20260210090023.2587534-1-mkchauras@gmail.com V5 -> V6: - Added a missing Tested by from Venkat which got missed since V3 - Support is marked as Maintained instead of experimental V5: https://lore.kernel.org/all/20260210053756.2088302-1-mkchauras@gmail.com V4 -> V5: - Removed a nested ifdef from PPC64 for Little endian toolchain V4: https://lore.kernel.org/all/20260209105456.1551677-1-mkchauras@gmail.com V3 -> V4: - Co-developed-by header added in patch 1 V3: https://lore.kernel.org/all/20260205180429.3280657-1-mkchauras@gmail.com V2 -> V3: - Splited HAVE_RUST in 2 lines - BINDGEN_TARGET_powerpc initialized before assigning the same to BINDGEN_TARGET V2: https://lore.kernel.org/all/20260204210125.613350-1-mkchauras@gmail.com V1 -> V2: - jump label fix for rust has been moved to a separate patch - PPC32 support has been taken - rust support has been marked experimental - target.json dependency has been removed - HAVE_RUST now depends on CPU_LITTLE_ENDIAN for PPC64 Link Mauve (2): rust: Make __udivdi3() and __umoddi3() panic rust: Add PowerPC support Mukesh Kumar Chaurasiya (IBM) (5): rust: Fix "multiple candidates for rmeta dependency core" error dma-resv: Fix undefined symbol when CONFIG_DMA_SHARED_BUFFER is disabled powerpc/jump_label: adjust inline asm to be consistent rust/powerpc: Set min rustc version for powerpc powerpc: Enable Rust for ppc64le arch/powerpc/Kconfig | 2 ++ arch/powerpc/Makefile | 7 ++++ arch/powerpc/include/asm/jump_label.h | 23 ++++++------ include/linux/dma-resv.h | 2 +- rust/Makefile | 52 +++++++++++++++++---------- rust/compiler_builtins.rs | 6 ++++ scripts/min-tool-version.sh | 6 +++- 7 files changed, 68 insertions(+), 30 deletions(-) -- 2.53.0

6 months, 2 weeks

[PATCH v12 0/5] Rust bindings for gem shmem

by Lyude Paul

Most of this patch series has already been pushed upstream, this is just the second half of the patch series that has not been pushed yet + some additional changes which were required to implement changes requested by the mailing list. This patch series is originally from Asahi, previously posted by Daniel Almeida. The previous version of the patch series can be found here: https://patchwork.freedesktop.org/series/164580/ Branch with patches applied available here sure this builds: https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem This patch series applies on top of drm-rust-next Lyude Paul (5): rust: drm: gem: s/device::Device/Device/ for shmem.rs drm/gem/shmem: Introduce __drm_gem_shmem_free_sgt_locked() drm/gem/shmem: Export drm_gem_shmem_get_pages_sgt_locked() rust: drm: gem: Introduce shmem::SGTable rust: drm: gem: Add vmap functions to shmem bindings drivers/gpu/drm/drm_gem_shmem_helper.c | 48 ++- include/drm/drm_gem_shmem_helper.h | 2 + rust/kernel/drm/gem/shmem.rs | 557 ++++++++++++++++++++++++- 3 files changed, 593 insertions(+), 14 deletions(-) base-commit: a7a080bb4236ebe577b6776d940d1717912ff6dd -- 2.53.0

6 months, 2 weeks

[PATCH v11 0/5] Rust bindings for gem shmem

by Lyude Paul

Most of this patch series has already been pushed upstream, this is just the second half of the patch series that has not been pushed yet + some additional changes which were required to implement changes requested by the mailing list. This patch series is originally from Asahi, previously posted by Daniel Almeida. The previous version of the patch series can be found here: https://patchwork.freedesktop.org/series/164580/ Branch with patches applied available here (+ a hack required to make sure this builds: https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem This patch series applies on top of drm-rust-next Lyude Paul (5): rust: drm: gem: s/device::Device/Device/ for shmem.rs drm/gem/shmem: Introduce __drm_gem_shmem_free_sgt_locked() drm/gem/shmem: Export drm_gem_shmem_get_pages_sgt_locked() rust: drm: gem: Introduce shmem::SGTable rust: drm: gem: Add vmap functions to shmem bindings drivers/gpu/drm/drm_gem_shmem_helper.c | 48 ++- include/drm/drm_gem_shmem_helper.h | 2 + rust/kernel/drm/gem/shmem.rs | 557 ++++++++++++++++++++++++- 3 files changed, 593 insertions(+), 14 deletions(-) base-commit: a7a080bb4236ebe577b6776d940d1717912ff6dd -- 2.53.0

6 months, 2 weeks

[PATCH v10 0/5] Rust bindings for gem shmem

by Lyude Paul

Most of this patch series has already been pushed upstream, this is just the second half of the patch series that has not been pushed yet + some additional changes which were required to implement changes requested by the mailing list. This patch series is originally from Asahi, previously posted by Daniel Almeida. The previous version of the patch series can be found here: (apparently it mistakenly was not sent to dri-devel, so no patchwork ): https://patchwork.freedesktop.org/series/156093/ Branch with patches applied available here (+ a hack required to make sure this builds: https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem Lyude Paul (5): rust: drm: gem: s/device::Device/Device/ for shmem.rs drm/gem/shmem: Introduce __drm_gem_shmem_free_sgt_locked() drm/gem/shmem: Export drm_gem_shmem_get_pages_sgt_locked() rust: drm: gem: Introduce shmem::SGTable rust: drm: gem: Add vmap functions to shmem bindings drivers/gpu/drm/drm_gem_shmem_helper.c | 48 ++- include/drm/drm_gem_shmem_helper.h | 2 + rust/kernel/drm/gem/shmem.rs | 553 ++++++++++++++++++++++++- 3 files changed, 590 insertions(+), 13 deletions(-) base-commit: a7a080bb4236ebe577b6776d940d1717912ff6dd -- 2.53.0

6 months, 3 weeks

Slithering into Fun: Mastering the Classic Snake Game

by serious.halibut.leeg＠hidingmail.com

The Snake Game – simple, addictive, and utterly timeless. It's a game that has graced countless screens, from early mobile phones to web browsers, and continues to be a source of casual entertainment for millions. But behind its deceptively simple premise lies a surprising amount of skill and strategy. Let's dive into how to not just play the Snake Game, but how to experience it. https://snakegame.onl Gameplay: A Simple Dance of Digits and Delight The core concept of the Snake Game is beautifully straightforward. You control a snake, initially a small line segment, navigating within a defined play area. Your goal? To consume food, typically represented by small dots or blocks, without crashing into the walls, your own body, or obstacles if any are present in the version you're playing. Each time your snake eats food, it grows longer, increasing the difficulty as maneuvering space becomes more constrained. The game ends when you collide with yourself or the boundaries of the play area. Sound easy? Try it! The real challenge lies in predicting future movements, planning efficient paths, and adapting to the ever-increasing length of your serpentine friend. Many variations of the Snake Game exist, often with added features like walls within the playing field, power-ups, and different control schemes. Some even offer multiplayer options, allowing you to compete against friends or other players online. Regardless of the specific version, the fundamental mechanics remain the same. Tips and Tricks: Becoming a Snake Charmer While the Snake Game appears luck-based at times, mastering a few key strategies can significantly improve your score and extend your gameplay: Plan Ahead: Don’t just react to the immediate situation. Try to anticipate your snake's movements several steps in advance. Visualize the path you'll need to take to collect the next food pellet without painting yourself into a corner. Utilize Corners: Corners are your best friends. They provide a temporary safe haven where you can change direction and reassess your surroundings. Master the art of hugging the walls and making sharp turns. Create Space: As your snake grows, space becomes a precious commodity. Aim to create loops and empty areas within the playing field to give yourself more room to maneuver. A well-executed loop can buy you valuable time and prevent a fatal crash. Patience is Key: Don’t rush. Sometimes the best strategy is to wait for an opportunity to present itself. Avoid making risky moves that could lead to a premature end. Learn the Algorithm (Sort Of): Some players find it beneficial to develop a mental "algorithm" or pattern for their snake's movements. This could involve consistently circling the outer edges of the play area or employing a specific sequence of turns. Experiment to find what works best for you. Embrace the Simplicity: A Timeless Classic The Snake Game is more than just a game; it's a piece of digital history. Its enduring appeal lies in its simplicity, accessibility, and addictive gameplay. Whether you're a seasoned veteran or a newcomer, there's always something to enjoy about this classic title. So, fire up your device, control your snake, and get ready for a slithering good time. You might be surprised at how engaging this seemingly simple game can be!

6 months, 3 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig