Linaro-mm-sig March 2026

linaro-mm-sig@lists.linaro.org

133 participants
1109 discussions

[PATCH v2 00/19] tracepoint: Avoid double static_branch evaluation at guarded call sites

by Vineeth Pillai (Google)

When a caller already guards a tracepoint with an explicit enabled check: if (trace_foo_enabled() && cond) trace_foo(args); trace_foo() internally re-evaluates the static_branch_unlikely() key. Since static branches are patched binary instructions the compiler cannot fold the two evaluations, so every such site pays the cost twice. This series introduces trace_call__##name() as a companion to trace_##name(). It calls __do_trace_##name() directly, bypassing the redundant static-branch re-check, while preserving all other correctness properties of the normal path (RCU-watching assertion, might_fault() for syscall tracepoints). The internal __do_trace_##name() symbol is not leaked to call sites; trace_call__##name() is the only new public API. if (trace_foo_enabled() && cond) trace_call__foo(args); /* calls __do_trace_foo() directly */ The first patch adds the three-location change to include/linux/tracepoint.h (__DECLARE_TRACE, __DECLARE_TRACE_SYSCALL, and the !TRACEPOINTS_ENABLED stub). The remaining 18 patches mechanically convert all guarded call sites found in the tree: kernel/, io_uring/, net/, accel/habanalabs, cpufreq/, devfreq/, dma-buf/, fsi/, drm/, HID, i2c/, spi/, scsi/ufs/, btrfs/, net/devlink/, kernel/time/, kernel/trace/, mm/damon/, and arch/x86/. This series is motivated by Peter Zijlstra's observation in the discussion around Dmitry Ilvokhin's locking tracepoint instrumentation series, where he noted that compilers cannot optimize static branches and that guarded call sites end up evaluating the static branch twice for no reason, and by Steven Rostedt's suggestion to add a proper API instead of exposing internal implementation details like __do_trace_##name() directly to call sites: https://lore.kernel.org/linux-trace-kernel/8298e098d3418cb446ef396f119edac5… Suggested-by: Steven Rostedt <rostedt(a)goodmis.org> Suggested-by: Peter Zijlstra <peterz(a)infradead.org> Changes in v2: - Renamed trace_invoke_##name() to trace_call__##name() (double underscore) per review comments. - Added 4 new patches covering sites missed in v1, found using coccinelle to scan the tree (Keith Busch): * net/devlink: guarded tracepoint_enabled() block in trap.c * kernel/time: early-return guard in tick-sched.c (tick_stop) * kernel/trace: early-return guard in trace_benchmark.c * mm/damon: early-return guard in core.c * arch/x86: do_trace_*() wrapper functions in lib/msr.c, which are called exclusively from tracepoint_enabled()-guarded sites in asm/msr.h v1: https://lore.kernel.org/linux-trace-kernel/abSqrJ1J59RQC47U@kbusch-mbp/ Vineeth Pillai (Google) (19): tracepoint: Add trace_call__##name() API kernel: Use trace_call__##name() at guarded tracepoint call sites io_uring: Use trace_call__##name() at guarded tracepoint call sites net: Use trace_call__##name() at guarded tracepoint call sites accel/habanalabs: Use trace_call__##name() at guarded tracepoint call sites cpufreq: Use trace_call__##name() at guarded tracepoint call sites devfreq: Use trace_call__##name() at guarded tracepoint call sites dma-buf: Use trace_call__##name() at guarded tracepoint call sites fsi: Use trace_call__##name() at guarded tracepoint call sites drm: Use trace_call__##name() at guarded tracepoint call sites HID: Use trace_call__##name() at guarded tracepoint call sites i2c: Use trace_call__##name() at guarded tracepoint call sites spi: Use trace_call__##name() at guarded tracepoint call sites scsi: ufs: Use trace_call__##name() at guarded tracepoint call sites btrfs: Use trace_call__##name() at guarded tracepoint call sites net: devlink: Use trace_call__##name() at guarded tracepoint call sites kernel: time, trace: Use trace_call__##name() at guarded tracepoint call sites mm: damon: Use trace_call__##name() at guarded tracepoint call sites x86: msr: Use trace_call__##name() at guarded tracepoint call sites arch/x86/lib/msr.c | 6 +++--- drivers/accel/habanalabs/common/device.c | 12 ++++++------ drivers/accel/habanalabs/common/mmu/mmu.c | 3 ++- drivers/accel/habanalabs/common/pci/pci.c | 4 ++-- drivers/cpufreq/amd-pstate.c | 10 +++++----- drivers/cpufreq/cpufreq.c | 2 +- drivers/cpufreq/intel_pstate.c | 2 +- drivers/devfreq/devfreq.c | 2 +- drivers/dma-buf/dma-fence.c | 4 ++-- drivers/fsi/fsi-master-aspeed.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 ++-- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- drivers/gpu/drm/scheduler/sched_entity.c | 4 ++-- drivers/hid/intel-ish-hid/ipc/pci-ish.c | 2 +- drivers/i2c/i2c-core-slave.c | 2 +- drivers/spi/spi-axi-spi-engine.c | 4 ++-- drivers/ufs/core/ufshcd.c | 12 ++++++------ fs/btrfs/extent_map.c | 4 ++-- fs/btrfs/raid56.c | 4 ++-- include/linux/tracepoint.h | 11 +++++++++++ io_uring/io_uring.h | 2 +- kernel/irq_work.c | 2 +- kernel/sched/ext.c | 2 +- kernel/smp.c | 2 +- kernel/time/tick-sched.c | 12 ++++++------ kernel/trace/trace_benchmark.c | 2 +- mm/damon/core.c | 2 +- net/core/dev.c | 2 +- net/core/xdp.c | 2 +- net/devlink/trap.c | 2 +- net/openvswitch/actions.c | 2 +- net/openvswitch/datapath.c | 2 +- net/sctp/outqueue.c | 2 +- net/tipc/node.c | 2 +- 35 files changed, 74 insertions(+), 62 deletions(-) -- 2.53.0

2 months, 3 weeks

How Funds Reclaimer Company Investigates Pig Butchering Fraud

by petersongreg565＠gmail.com

I am writing to express my deepest gratitude to FUNDS RECLAIMER COMPANY for their invaluable assistance in recovering my Bitcoin, which was unfortunately lost to a scammer. The expertise and professionalism displayed by their team were instrumental in retrieving my stolen funds, and I am truly thankful for their support throughout this ordeal. After falling victim to a sophisticated scam, I thought all hope was lost, and my Bitcoin was gone for good. However, I decided to reach out to FUNDS RECLAIMER COMPANY, and their team promptly responded with a clear plan of action to recover my stolen funds. Their dedication and expertise in navigating the complexities of cryptocurrency transactions were impressive, and they worked tirelessly to track down the scammer and retrieve my Bitcoin. The entire process, from initial consultation to the final recovery of my funds, was handled with utmost care and transparency. The team at FUNDS RECLAIMER COMPANY kept me informed every step of the way, providing regular updates on the progress of the recovery efforts. Their commitment to customer satisfaction was evident in the way they handled my case, and I was constantly reassured that my case was being treated with the utmost importance. I am thrilled to have my Bitcoin back, and I attribute this success entirely to the exceptional work of FUNDS RECLAIMER COMPANY. Their knowledge and experience in dealing with cryptocurrency scams are unparalleled, and I would highly recommend their services to anyone who has fallen victim to similar situations. The company's expertise and professionalism are a beacon of hope for those who have lost their funds to scammers, and I am living proof of their ability to deliver results. In conclusion, I would like to extend my sincerest appreciation to FUNDS RECLAIMER COMPANY for their outstanding service and support. Their expertise and dedication have given me a second chance to recover my lost Bitcoin, and I will be forever grateful for their help. If you or someone you know has been a victim of a cryptocurrency scam, I strongly recommend reaching out to FUNDS RECLAIMER COMPANY for assistance. They are truly the experts in recovering lost funds, and their professionalism and transparency make them a trusted partner in the fight against scammers. Info Below: Website: https//:funds-reclaimercompany.org Email: fundsreclaimer(a)consultant.com

2 months, 3 weeks

[PATCH 0/8] drm/imagination: Job submission fixes and cleanup

by Alessio Belle

The first two commits fix rare bugs and should be backported to stable branches. The rest is an attempt to cleanup and document the code to make it a bit easier to understand. Signed-off-by: Alessio Belle <alessio.belle(a)imgtec.com> --- Alessio Belle (8): drm/imagination: Count paired job fence as dependency in prepare_job() drm/imagination: Fit paired fragment job in the correct CCCB drm/imagination: Skip check on paired job fence during job submission drm/imagination: Rename pvr_queue_fence_is_ufo_backed() to reflect usage drm/imagination: Rename fence returned by pvr_queue_job_arm() drm/imagination: Move repeated job fence check to its own function drm/imagination: Update check to skip prepare_job() for fragment jobs drm/imagination: Minor improvements to job submission code documentation drivers/gpu/drm/imagination/pvr_job.c | 8 +- drivers/gpu/drm/imagination/pvr_queue.c | 154 +++++++++++++-------- drivers/gpu/drm/imagination/pvr_queue.h | 2 +- .../gpu/drm/imagination/pvr_rogue_fwif_shared.h | 10 +- drivers/gpu/drm/imagination/pvr_sync.c | 8 +- drivers/gpu/drm/imagination/pvr_sync.h | 2 +- 6 files changed, 110 insertions(+), 74 deletions(-) --- base-commit: 3bce3fdd1ff2ba242f76ab66659fff27207299f1 change-id: 20260330-job-submission-fixes-cleanup-83e01196c3e9 Best regards, -- Alessio Belle <alessio.belle(a)imgtec.com>

2 months, 3 weeks

[PATCH] mm/vmalloc: map contiguous pages in batches for vmap() whenever possible

by Barry Song

From: Barry Song <v-songbaohua(a)oppo.com> In many cases, the pages passed to vmap() may include high-order pages allocated with __GFP_COMP flags. For example, the systemheap often allocates pages in descending order: order 8, then 4, then 0. Currently, vmap() iterates over every page individually—even pages inside a high-order block are handled one by one. This patch detects high-order pages and maps them as a single contiguous block whenever possible. An alternative would be to implement a new API, vmap_sg(), but that change seems to be large in scope. When vmapping a 128MB dma-buf using the systemheap, this patch makes system_heap_do_vmap() roughly 17× faster. W/ patch: [ 10.404769] system_heap_do_vmap took 2494000 ns [ 12.525921] system_heap_do_vmap took 2467008 ns [ 14.517348] system_heap_do_vmap took 2471008 ns [ 16.593406] system_heap_do_vmap took 2444000 ns [ 19.501341] system_heap_do_vmap took 2489008 ns W/o patch: [ 7.413756] system_heap_do_vmap took 42626000 ns [ 9.425610] system_heap_do_vmap took 42500992 ns [ 11.810898] system_heap_do_vmap took 42215008 ns [ 14.336790] system_heap_do_vmap took 42134992 ns [ 16.373890] system_heap_do_vmap took 42750000 ns Cc: David Hildenbrand <david(a)kernel.org> Cc: Uladzislau Rezki <urezki(a)gmail.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: John Stultz <jstultz(a)google.com> Cc: Maxime Ripard <mripard(a)kernel.org> Tested-by: Tangquan Zheng <zhengtangquan(a)oppo.com> Signed-off-by: Barry Song <v-songbaohua(a)oppo.com> --- * diff with rfc: Many code refinements based on David's suggestions, thanks! Refine comment and changelog according to Uladzislau, thanks! rfc link: https://lore.kernel.org/linux-mm/20251122090343.81243-1-21cnbao@gmail.com/ mm/vmalloc.c | 45 +++++++++++++++++++++++++++++++++++++++------ 1 file changed, 39 insertions(+), 6 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 41dd01e8430c..8d577767a9e5 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -642,6 +642,29 @@ static int vmap_small_pages_range_noflush(unsigned long addr, unsigned long end, return err; } +static inline int get_vmap_batch_order(struct page **pages, + unsigned int stride, unsigned int max_steps, unsigned int idx) +{ + int nr_pages = 1; + + /* + * Currently, batching is only supported in vmap_pages_range + * when page_shift == PAGE_SHIFT. + */ + if (stride != 1) + return 0; + + nr_pages = compound_nr(pages[idx]); + if (nr_pages == 1) + return 0; + if (max_steps < nr_pages) + return 0; + + if (num_pages_contiguous(&pages[idx], nr_pages) == nr_pages) + return compound_order(pages[idx]); + return 0; +} + /* * vmap_pages_range_noflush is similar to vmap_pages_range, but does not * flush caches. @@ -655,23 +678,33 @@ int __vmap_pages_range_noflush(unsigned long addr, unsigned long end, pgprot_t prot, struct page **pages, unsigned int page_shift) { unsigned int i, nr = (end - addr) >> PAGE_SHIFT; + unsigned int stride; WARN_ON(page_shift < PAGE_SHIFT); + /* + * For vmap(), users may allocate pages from high orders down to + * order 0, while always using PAGE_SHIFT as the page_shift. + * We first check whether the initial page is a compound page. If so, + * there may be an opportunity to batch multiple pages together. + */ if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMALLOC) || - page_shift == PAGE_SHIFT) + (page_shift == PAGE_SHIFT && !PageCompound(pages[0]))) return vmap_small_pages_range_noflush(addr, end, prot, pages); - for (i = 0; i < nr; i += 1U << (page_shift - PAGE_SHIFT)) { - int err; + stride = 1U << (page_shift - PAGE_SHIFT); + for (i = 0; i < nr; ) { + int err, order; - err = vmap_range_noflush(addr, addr + (1UL << page_shift), + order = get_vmap_batch_order(pages, stride, nr - i, i); + err = vmap_range_noflush(addr, addr + (1UL << (page_shift + order)), page_to_phys(pages[i]), prot, - page_shift); + page_shift + order); if (err) return err; - addr += 1UL << page_shift; + addr += 1UL << (page_shift + order); + i += 1U << (order + page_shift - PAGE_SHIFT); } return 0; -- 2.39.3 (Apple Git-146)

2 months, 4 weeks

Understanding Blockchain Forensics:

by joelwest689＠gmail.com

By combining cross-chain tracing, rapid response, and data-driven investigation, Cipher Rescue Chain stands as the global benchmark for crypto recovery. Every traced transaction, every reconstructed path, and every recovered asset reinforces the same conclusion: with the right forensic expertise, recovery is not only possible—it is highly achievable.

2 months, 4 weeks

[PATCH] dma-buf: set SB_I_NOEXEC and SB_I_NODEV on dmabuf filesystem

by Chia-Lin Kao (AceLan)

The VFS now warns if an inode flagged with S_ANON_INODE is located on a filesystem that does not have SB_I_NOEXEC set. dmabuf inodes are created using alloc_anon_inode(), which sets S_ANON_INODE. This triggers a warning in path_noexec() when a dmabuf is mmapped, for example by GStreamer's v4l2src element. [ 60.061328] WARNING: CPU: 2 PID: 2803 at fs/exec.c:125 path_noexec+0xa0/0xd0 ... [ 60.061637] do_mmap+0x2b5/0x680 The warning was introduced by commit 1e7ab6f67824 ("anon_inode: rework assertions") which added enforcement that anonymous inodes must be on filesystems with SB_I_NOEXEC set. Fix this by setting SB_I_NOEXEC and SB_I_NODEV on the dmabuf filesystem context, following the same pattern as commit ce7419b6cf23d ("anon_inode: raise SB_I_NODEV and SB_I_NOEXEC") and commit 98f99394a104c ("secretmem: use SB_I_NOEXEC"). Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao(a)canonical.com> --- drivers/dma-buf/dma-buf.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index a4d8f2ff94e46..dea79aaab10ce 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -221,6 +221,8 @@ static int dma_buf_fs_init_context(struct fs_context *fc) if (!ctx) return -ENOMEM; ctx->dops = &dma_buf_dentry_ops; + fc->s_iflags |= SB_I_NOEXEC; + fc->s_iflags |= SB_I_NODEV; return 0; } -- 2.51.0

2 months, 4 weeks

[PATCH] dma-fence: Move signalling tracepoint to before ops detach

by Tvrtko Ursulin

Move the signalling tracepoint to before fence->ops are reset otherwise tracepoint will dereference a null pointer. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3") Cc: Christian König <christian.koenig(a)amd.com> Cc: Philipp Stanner <phasta(a)kernel.org> Cc: Boris Brezillon <boris.brezillon(a)collabora.com> Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org --- drivers/dma-buf/dma-fence.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 1826ba73094c..1c1eaecaf1b0 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -363,6 +363,8 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, &fence->flags))) return; + trace_dma_fence_signaled(fence); + /* * When neither a release nor a wait operation is specified set the ops * pointer to NULL to allow the fence structure to become independent @@ -377,7 +379,6 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, fence->timestamp = timestamp; set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags); - trace_dma_fence_signaled(fence); list_for_each_entry_safe(cur, tmp, &cb_list, node) { INIT_LIST_HEAD(&cur->node); -- 2.52.0

2 months, 4 weeks

[PATCH v4 0/8] dma-buf: heaps: Turn heaps into modules

by Maxime Ripard

Hi, The recent introduction of heaps in the optee driver [1] made possible the creation of heaps as modules. It's generally a good idea if possible, including for the already existing system and CMA heaps. The system one is pretty trivial, the CMA one is a bit more involved, especially since we have a call from kernel/dma/contiguous.c to the CMA heap code. This was solved by turning the logic around and making the CMA heap call into the contiguous DMA code. Let me know what you think, Maxime 1: https://lore.kernel.org/dri-devel/20250911135007.1275833-4-jens.wiklander@l… Signed-off-by: Maxime Ripard <mripard(a)kernel.org> --- Changes in v4: - Fix compilation failure - Rework to take into account OF_RESERVED_MEM - Fix regression making the default CMA area disappear if not created through the DT - Added some documentation and comments - Link to v3: https://lore.kernel.org/r/20260303-dma-buf-heaps-as-modules-v3-0-24344812c7… Changes in v3: - Squashed cma_get_name and cma_alloc/release patches - Fixed typo in Export dev_get_cma_area commit title - Fixed compilation failure with DMA_CMA but not OF_RESERVED_MEM - Link to v2: https://lore.kernel.org/r/20260227-dma-buf-heaps-as-modules-v2-0-454aee7e06… Changes in v2: - Collect tags - Don't export dma_contiguous_default_area anymore, but export dev_get_cma_area instead - Mentioned that heap modules can't be removed - Link to v1: https://lore.kernel.org/r/20260225-dma-buf-heaps-as-modules-v1-0-2109225a09… --- Maxime Ripard (8): dma: contiguous: Turn heap registration logic around dma: contiguous: Make dev_get_cma_area() a proper function dma: contiguous: Make dma_contiguous_default_area static dma: contiguous: Export dev_get_cma_area() mm: cma: Export cma_alloc(), cma_release() and cma_get_name() dma-buf: heaps: Export mem_accounting parameter dma-buf: heaps: cma: Turn the heap into a module dma-buf: heaps: system: Turn the heap into a module drivers/dma-buf/dma-heap.c | 1 + drivers/dma-buf/heaps/Kconfig | 4 +-- drivers/dma-buf/heaps/cma_heap.c | 22 +++---------- drivers/dma-buf/heaps/system_heap.c | 5 +++ include/linux/dma-buf/heaps/cma.h | 16 --------- include/linux/dma-map-ops.h | 14 ++++---- kernel/dma/contiguous.c | 66 +++++++++++++++++++++++++++++++++---- mm/cma.c | 3 ++ 8 files changed, 82 insertions(+), 49 deletions(-) --- base-commit: c081b71f11732ad2c443f170ab19c3ebe8a1a422 change-id: 20260225-dma-buf-heaps-as-modules-1034b3ec9f2a Best regards, -- Maxime Ripard <mripard(a)kernel.org>

3 months, 1 week

[PATCH RFC 00/18] accel/qda: Introduce Qualcomm DSP Accelerator driver

by Ekansh Gupta

This patch series introduces the Qualcomm DSP Accelerator (QDA) driver, a modern DRM-based accelerator implementation for Qualcomm Hexagon DSPs. The driver provides a standardized interface for offloading computational tasks to DSPs found on Qualcomm SoCs, supporting all DSP domains (ADSP, CDSP, SDSP, GDSP). The QDA driver is designed as an alternative for the FastRPC driver in drivers/misc/, offering improved resource management, better integration with standard kernel subsystems, and alignment with the Linux kernel's Compute Accelerators framework. User-space staging branch ============ https://github.com/qualcomm/fastrpc/tree/accel/staging Key Features ============ * Standard DRM accelerator interface via /dev/accel/accelN * GEM-based buffer management with DMA-BUF import/export support * IOMMU-based memory isolation using per-process context banks * FastRPC protocol implementation for DSP communication * RPMsg transport layer for reliable message passing * Support for all DSP domains (ADSP, CDSP, SDSP, GDSP) * Comprehensive IOCTL interface for DSP operations High-Level Architecture Differences with Existing FastRPC Driver ================================================================= The QDA driver represents a significant architectural departure from the existing FastRPC driver (drivers/misc/fastrpc.c), addressing several key limitations while maintaining protocol compatibility: 1. DRM Accelerator Framework Integration - FastRPC: Custom character device (/dev/fastrpc-*) - QDA: Standard DRM accel device (/dev/accel/accelN) - Benefit: Leverages established DRM infrastructure for device management. 2. Memory Management - FastRPC: Custom memory allocator with ION/DMA-BUF integration - QDA: Native GEM objects with full PRIME support - Benefit: Seamless buffer sharing using standard DRM mechanisms 3. IOMMU Context Bank Management - FastRPC: Direct IOMMU domain manipulation, limited isolation - QDA: Custom compute bus (qda_cb_bus_type) with proper device model - Benefit: Each CB device is a proper struct device with IOMMU group support, enabling better isolation and resource tracking. - https://lore.kernel.org/all/245d602f-3037-4ae3-9af9-d98f37258aae@oss.qualco… 4. Memory Manager Architecture - FastRPC: Monolithic allocator - QDA: Pluggable memory manager with backend abstraction - Benefit: Currently uses DMA-coherent backend, easily extensible for future memory types (e.g., carveout, CMA) 5. Transport Layer - FastRPC: Direct RPMsg integration in core driver - QDA: Abstracted transport layer (qda_rpmsg.c) - Benefit: Clean separation of concerns, easier to add alternative transports if needed 8. Code Organization - FastRPC: ~3000 lines in single file - QDA: Modular design across multiple files (~4600 lines total) * qda_drv.c: Core driver and DRM integration * qda_gem.c: GEM object management * qda_memory_manager.c: Memory and IOMMU management * qda_fastrpc.c: FastRPC protocol implementation * qda_rpmsg.c: Transport layer * qda_cb.c: Context bank device management - Benefit: Better maintainability, clearer separation of concerns 9. UAPI Design - FastRPC: Custom IOCTL interface - QDA: DRM-style IOCTLs with proper versioning support - Benefit: Follows DRM conventions, easier userspace integration 10. Documentation - FastRPC: Minimal in-tree documentation - QDA: Comprehensive documentation in Documentation/accel/qda/ - Benefit: Better developer experience, clearer API contracts 11. Buffer Reference Mechanism - FastRPC: Uses buffer file descriptors (FDs) for all book-keeping in both kernel and DSP - QDA: Uses GEM handles for kernel-side management, providing better integration with DRM subsystem - Benefit: Leverages DRM GEM infrastructure for reference counting, lifetime management, and integration with other DRM components Key Technical Improvements =========================== * Proper device model: CB devices are real struct device instances on a custom bus, enabling proper IOMMU group management and power management integration * Reference-counted IOMMU devices: Multiple file descriptors from the same process share a single IOMMU device, reducing overhead * GEM-based buffer lifecycle: Automatic cleanup via DRM GEM reference counting, eliminating many resource leak scenarios * Modular memory backends: The memory manager supports pluggable backends, currently implementing DMA-coherent allocations with SID-prefixed addresses for DSP firmware * Context-based invocation tracking: XArray-based context management with proper synchronization and cleanup Patch Series Organization ========================== Patches 1-2: Driver skeleton and documentation Patches 3-6: RPMsg transport and IOMMU/CB infrastructure Patches 7-9: DRM device registration and basic IOCTL Patches 10-12: GEM buffer management and PRIME support Patches 13-17: FastRPC protocol implementation (attach, invoke, create, map/unmap) Patch 18: MAINTAINERS entry Open Items =========== The following items are identified as open items: 1. Privilege Level Management - Currently, daemon processes and user processes have the same access level as both use the same accel device node. This needs to be addressed as daemons attach to privileged DSP PDs and require higher privilege levels for system-level operations - Seeking guidance on the best approach: separate device nodes, capability-based checks, or DRM master/authentication mechanisms 2. UAPI Compatibility Layer - Add UAPI compat layer to facilitate migration of client applications from existing FastRPC UAPI to the new QDA accel driver UAPI, ensuring smooth transition for existing userspace code - Seeking guidance on implementation approach: in-kernel translation layer, userspace wrapper library, or hybrid solution 3. Documentation Improvements - Add detailed IOCTL usage examples - Document DSP firmware interface requirements - Create migration guide from existing FastRPC 4. Per-Domain Memory Allocation - Develop new userspace API to support memory allocation on a per domain basis, enabling domain-specific memory management and optimization 5. Audio and Sensors PD Support - The current patch series does not handle Audio PD and Sensors PD functionalities. These specialized protection domains require additional support for real-time constraints and power management Interface Compatibility ======================== The QDA driver maintains compatibility with existing FastRPC infrastructure: * Device Tree Bindings: The driver uses the same device tree bindings as the existing FastRPC driver, ensuring no changes are required to device tree sources. The "qcom,fastrpc" compatible string and child node structure remain unchanged. * Userspace Interface: While the driver provides a new DRM-based UAPI, the underlying FastRPC protocol and DSP firmware interface remain compatible. This ensures that DSP firmware and libraries continue to work without modification. * Migration Path: The modular design allows for gradual migration, where both drivers can coexist during the transition period. Applications can be migrated incrementally to the new UAPI with the help of the planned compatibility layer. References ========== Previous discussions on this migration: - https://lkml.org/lkml/2024/6/24/479 - https://lkml.org/lkml/2024/6/21/1252 Testing ======= The driver has been tested on Qualcomm platforms with: - Basic FastRPC attach/release operations - DSP process creation and initialization - Memory mapping/unmapping operations - Dynamic invocation with various buffer types - GEM buffer allocation and mmap - PRIME buffer import from other subsystems Signed-off-by: Ekansh Gupta <ekansh.gupta(a)oss.qualcomm.com> --- Ekansh Gupta (18): accel/qda: Add Qualcomm QDA DSP accelerator driver docs accel/qda: Add Qualcomm DSP accelerator driver skeleton accel/qda: Add RPMsg transport for Qualcomm DSP accelerator accel/qda: Add built-in compute CB bus for QDA and integrate with IOMMU accel/qda: Create compute CB devices on QDA compute bus accel/qda: Add memory manager for CB devices accel/qda: Add DRM accel device registration for QDA driver accel/qda: Add per-file DRM context and open/close handling accel/qda: Add QUERY IOCTL and basic QDA UAPI header accel/qda: Add DMA-backed GEM objects and memory manager integration accel/qda: Add GEM_CREATE and GEM_MMAP_OFFSET IOCTLs accel/qda: Add PRIME dma-buf import support accel/qda: Add initial FastRPC attach and release support accel/qda: Add FastRPC dynamic invocation support accel/qda: Add FastRPC DSP process creation support accel/qda: Add FastRPC-based DSP memory mapping support accel/qda: Add FastRPC-based DSP memory unmapping support MAINTAINERS: Add MAINTAINERS entry for QDA driver Documentation/accel/index.rst | 1 + Documentation/accel/qda/index.rst | 14 + Documentation/accel/qda/qda.rst | 129 ++++ MAINTAINERS | 9 + arch/arm64/configs/defconfig | 2 + drivers/accel/Kconfig | 1 + drivers/accel/Makefile | 2 + drivers/accel/qda/Kconfig | 35 ++ drivers/accel/qda/Makefile | 19 + drivers/accel/qda/qda_cb.c | 182 ++++++ drivers/accel/qda/qda_cb.h | 26 + drivers/accel/qda/qda_compute_bus.c | 23 + drivers/accel/qda/qda_drv.c | 375 ++++++++++++ drivers/accel/qda/qda_drv.h | 171 ++++++ drivers/accel/qda/qda_fastrpc.c | 1002 ++++++++++++++++++++++++++++++++ drivers/accel/qda/qda_fastrpc.h | 433 ++++++++++++++ drivers/accel/qda/qda_gem.c | 211 +++++++ drivers/accel/qda/qda_gem.h | 103 ++++ drivers/accel/qda/qda_ioctl.c | 271 +++++++++ drivers/accel/qda/qda_ioctl.h | 118 ++++ drivers/accel/qda/qda_memory_dma.c | 91 +++ drivers/accel/qda/qda_memory_dma.h | 46 ++ drivers/accel/qda/qda_memory_manager.c | 382 ++++++++++++ drivers/accel/qda/qda_memory_manager.h | 148 +++++ drivers/accel/qda/qda_prime.c | 194 +++++++ drivers/accel/qda/qda_prime.h | 43 ++ drivers/accel/qda/qda_rpmsg.c | 327 +++++++++++ drivers/accel/qda/qda_rpmsg.h | 57 ++ drivers/iommu/iommu.c | 4 + include/linux/qda_compute_bus.h | 22 + include/uapi/drm/qda_accel.h | 224 +++++++ 31 files changed, 4665 insertions(+) --- base-commit: d4906ae14a5f136ceb671bb14cedbf13fa560da6 change-id: 20260223-qda-firstpost-4ab05249e2cc Best regards, -- Ekansh Gupta <ekansh.gupta(a)oss.qualcomm.com>

3 months, 1 week

[PATCH v3 0/6] dma-buf: heaps: add coherent reserved-memory heap

by Albert Esteve

This patch series adds a new dma-buf heap driver that exposes coherent, non‑reusable reserved-memory regions as named heaps, so userspace can explicitly allocate buffers from those device‑specific pools. Motivation: we want cgroup accounting for all userspace‑visible buffer allocations (DRM, v4l2, dma‑buf heaps, etc.). That’s hard to do when drivers call dma_alloc_attrs() directly because the accounting controller (memcg vs dmem) is ambiguous. The long‑term plan is to steer those paths toward dma‑buf heaps, where each heap can unambiguously charge a single controller. To reach that goal, we need a heap backend for each dma_alloc_attrs() memory type. CMA and system heaps already exist; coherent reserved‑memory was the missing piece, since many SoCs define dedicated, device‑local coherent pools in DT under /reserved-memory using "shared-dma-pool" with non‑reusable regions (i.e., not CMA) that are carved out exclusively for coherent DMA and are currently only usable by in‑kernel drivers. Because these regions are device‑dependent, each heap instance binds a heap device to its reserved‑mem region via a newly introduced helper function -namely, of_reserved_mem_device_init_with_mem()- so coherent allocations use the correct dev->dma_mem. Charging to cgroups for these buffers is intentionally left out to keep review focused on the new heap; I plan to follow up based on Eric’s [1] and Maxime’s [2] work on dmem charging from userspace. This series also makes the new heap driver modular, in line with the CMA heap change in [3]. [1] https://lore.kernel.org/all/20260218-dmabuf-heap-cma-dmem-v2-0-b249886fb7b2… [2] https://lore.kernel.org/all/20250310-dmem-cgroups-v1-0-2984c1bc9312@kernel.… [3] https://lore.kernel.org/all/20260303-dma-buf-heaps-as-modules-v3-0-24344812… Signed-off-by: Albert Esteve <aesteve(a)redhat.com> --- Changes in v3: - Reorganized changesets among patches to ensure bisectability - Removed unused dma_heap_coherent_register() leftover - Removed fallback when setting mask in coherent heap dev, since dma_set_mask() already truncates to supported masks - Moved struct rmem_assigned_device (rd) logic to of_reserved_mem_device_init_with_mem() to allow listing the device - Link to v2: https://lore.kernel.org/r/20260303-b4-dmabuf-heap-coherent-rmem-v2-0-65a465… Changes in v2: - Removed dmem charging parts - Moved coherent heap registering logic to coherent.c - Made heap device a member of struct dma_heap - Split dma_heap_add logic into create/register, to be able to access the stored heap device before registered. - Avoid platform device in favour of heap device - Added a wrapper to rmem device_init() op - Switched from late_initcall() to module_init() - Made the coherent heap driver modular - Link to v1: https://lore.kernel.org/r/20260224-b4-dmabuf-heap-coherent-rmem-v1-1-dffef4… --- Albert Esteve (5): dma-buf: dma-heap: split dma_heap_add of_reserved_mem: add a helper for rmem device_init op dma: coherent: store reserved memory coherent regions dma-buf: heaps: Add Coherent heap to dmabuf heaps dma-buf: heaps: coherent: Turn heap into a module John Stultz (1): dma-buf: dma-heap: Keep track of the heap device struct drivers/dma-buf/dma-heap.c | 138 +++++++++-- drivers/dma-buf/heaps/Kconfig | 9 + drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/coherent_heap.c | 417 ++++++++++++++++++++++++++++++++++ drivers/of/of_reserved_mem.c | 68 ++++-- include/linux/dma-heap.h | 5 + include/linux/dma-map-ops.h | 7 + include/linux/of_reserved_mem.h | 8 + kernel/dma/coherent.c | 34 +++ 9 files changed, 640 insertions(+), 47 deletions(-) --- base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f change-id: 20260223-b4-dmabuf-heap-coherent-rmem-91fd3926afe9 Best regards, -- Albert Esteve <aesteve(a)redhat.com>

3 months, 1 week

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig March 2026