Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

10 participants
3693 discussions

Re: [PATCH] dma-buf: Reject private mappings in dma_buf_mmap_internal() and dma_buf_mmap()

by T.J. Mercier

On Mon, Nov 2, 2026 at 8:00 AM Chris Wiseman <chriswiseman(a)google.com> wrote: > > DMA-BUF mappings do not support copy-on-write. Mapping a dma-buf with > MAP_PRIVATE and PROT_WRITE faults into do_wp_page() -> wp_page_copy() > and allocates private anonymous pages whose writes never reach the > underlying buffer. > > Individual exporters like cma_heap_mmap(), system_heap_mmap(), and > mmap_udmabuf() already require (VM_SHARED | VM_MAYSHARE), and DRM > helpers like ttm_bo_mmap_obj() and drm_gem_shmem_object_mmap() reject > vma_is_cow_mapping(vma). However, dma_buf_mmap_internal() and > dma_buf_mmap() do not check for this and pass MAP_PRIVATE mappings > straight through to dmabuf->ops->mmap(). > > Reject mappings with -EINVAL in both dma_buf_mmap_internal() and > dma_buf_mmap() when neither VM_SHARED nor VM_MAYSHARE is set. Checking > both flags still allows read-only MAP_SHARED mappings, where do_mmap() > clears VM_SHARED and leaves VM_MAYSHARE set. > > Suggested-by: T.J. Mercier <tjmercier(a)google.com> > Suggested-by: Christian König <christian.koenig(a)amd.com> > Signed-off-by: Chris Wiseman <chriswiseman(a)google.com> I really hope nobody is trying to CoW with dma-bufs. Reviewed-by: T.J. Mercier <tjmercier(a)google.com>

32 minutes

[PATCH v12 00/19] PCI/P2PDMA: Route peer-to-peer DMA by TLP class

by Leon Romanovsky

PCI P2PDMA applies Request and Completion Redirect throughout both paths. This misclassifies asymmetric and nested switches, and reports one answer for every kind of TLP. Three ACS controls act on TLP attributes the Requester chooses rather than on the topology: Translation Blocking and Direct Translated P2P act on a Request's Address Type, and Completion Redirect skips Completions carrying Relaxed Ordering. Evaluate each direction at the path divergence, decide every class from the one walk, and treat a client with ATS enabled as translating unless its driver declares per-mapping ATS. This completes the P2PDMA side; dma-buf and mlx5 follow separately. Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> --- Changes in v12: - Rebaed to v7.4-rc1 - Link to v11: https://patch.msgid.link/20261013-fix-p2p-acs-v4-0-v11-0-72cf8c96e617@nvidi… Changes in v11: - Applied the client ATS policy in pci_p2pdma_distance_many() too, as local Sashiko pointed out. - Read the ATS Enable bit once per query, so the class and the ATS policy always agree. - Documented that pcim_p2pdma_set_ats_per_mapping() needs a successful pcim_p2pdma_init(). - The path diagnostics no longer read ACS Control or the bridge bus range, and they report a failed cache store. - Added a KUnit case for Direct Translated P2P without a redirect. - Clarified the Relaxed Ordering and diagnostics commit messages. - Honored device-specific ACS redirection, such as Zhaoxin Downstream Ports, in a new first patch with a KUnit case, as local Sashiko pointed out. Relaxed Ordering Completions are redirected at such a port too. - Clarified in the documentation that a quirk also redirects Relaxed Ordering Completions and that Translation Blocking applies only to upstream Requests, and labelled the ACS routing debug line with its class, as local Sashiko pointed out. - Treated ACS registers that read as all ones as unreadable, and named ports that a quirk redirects instead of suggesting pci=disable_acs_redir= for them, as local Sashiko pointed out. - Ignored ACS quirks of endpoints, which only describe traffic between their own functions. - Link to v10: https://patch.msgid.link/20261012-fix-p2p-acs-v4-0-v10-0-6ffe7b7a4517@nvidi… Changes in v10: - Fixed the Relaxed Ordering description: a Completion carries the attribute of its Request (PCIe r7.0 sec 2.2.9.1). - Used the PCIe terms Requester and Completer for TLPs, ACS and ports; client and provider remain for P2PDMA objects. - Rebased on pci/p2pdma, which includes the prerequisite P2PDMA fixes. - Added a topology example to the path divergence patch. - Removed a repeated sentence from the disable_acs_redir documentation. - Explained the path divergence in the documentation. - Link to v9: https://patch.msgid.link/20261001-fix-p2p-acs-v4-0-v9-0-1a8e0f50ddd9@nvidia… Changes in v9: - Removed dmabuf patches for now. - Removed mlx5 per-mapping ATS declaration for now; it comes back with the dmabuf patches. - Link to v8: https://patch.msgid.link/20260928-fix-p2p-acs-v4-0-v8-0-404453b9c435@nvidia… Changes in v8: - Added extra Reviewed-by from Logan. - Added patches to take care of ATS per-device vs. per-mapping option - Link to v7: https://patch.msgid.link/20260920-fix-p2p-acs-v4-0-v7-0-ca0828ab697c@nvidia… Changes in v7: - Removed "Document pdev->p2pdma lifetime rules" patch, it gives nothing after p2pmem fix. - Split dmabuf patch. - Tushar retested the series, so added his Tested-by. - Added Logan's ROB tags and fixed minor documentation issues pointed by him. - Link to v6: https://lore.kernel.org/all/20260914-fix-p2p-acs-v4-0-v6-0-5ef07ec9ef06@nvi… Changes in v6: - Changed DMABUF to use callbacks and not directly stored pointer. - Link to v5: https://patch.msgid.link/20260910-fix-p2p-acs-v4-0-v5-0-856087f63c0d@nvidia… Changes in v5: - Rebase on the posted fixes. - Dropped tags from changed patches. - Remove Egress Control Vector interpretation and coverage. - Keep enabled Egress Control conservative as a Request redirect. - Use pci_dbg()/dev_dbg() for diagnostics and drop the "debug" prefix. - Removed code comments from "Document the pdev->p2pdma lifetime and RCU rules" patch and reduced description to actual lifetime explanation. - Added note that Linux assumes that TLPs are in strict-ordering and untranslated. - Added code to calculate p2p paths per-TLP type. - Converted mlx5 to use that new proposed API. - Link to https://patch.msgid.link/20260821-fix-p2p-acs-v4-0-v4-0-94426b96de73@nvidia… Changes in v4: - Reject ACS Violations and unreadable routing state instead of treating them as host-bridge redirects - Added Tested-by tags from Tushar Dave - Added support to asymmetric ACS routing - Limited redirect checks to the two ports at the path divergence - Added standalone ACS routing diagnostics for hardware retesting - Dropped " PCI: Account for Direct Translated P2P in ACS isolation checks" patch - Link to v3: https://patch.msgid.link/20260811-fix-p2p-acs-v3-0-efc488ee7c03@nvidia.com Changes in v3: - Fixed pci_p2pdma_add_resource() error unwinding - Made pdev->p2pdma teardown wait unconditionally for RCU readers - Restricted pci_p2pmem_find_many() to pool-backed providers - Documented the pdev->p2pdma lifetime and RCU rules - Fixed calc_map_type_and_dist() handling of the verbose argument - Required the ACS port and target to share a bus before indexing the Egress Control Vector - Gave pci_acs_enabled() and pci_acs_path_enabled() a scope, so the ACS Direct Translated P2P rule no longer stops pci_enable_pasid() from enabling PASID - Dropped "Report ACS ports when the paths share no upstream bridge": the mapping type cannot change without a shared upstream bridge, so the pci=disable_acs_redir= hint was not actionable there and the ACS walk only cost config space reads - Folded the Request Redirect rule into pci_acs_rr_ineffective(), so pci_acs_flags_enabled() and the Intel SPT PCH quirk share one copy - Renamed pci_acs_egress_ctrl_set() to pci_acs_egress_ctrl_is_set(), it reads the bit rather than setting it - Reworded the blocked-path warning: ACS may also leave the direct route indeterminate rather than blocked - Added KUnit coverage for the shared-bus guard, a device with no ACS capability and an unreadable ACS Control register - Added the missing Fixes: tags, a second one on the pci_p2pdma_add_resource() unwinding fix (the dangling devres action dates to f58ef9d1d135) and one on the Egress Control isolation change - Link to v2: https://patch.msgid.link/20260806-fix-p2p-acs-v2-0-0cec14812965@nvidia.com Changes in v2: - Added Logan's ROB tags - Added commas in Documentation patch - Link to v1: https://patch.msgid.link/20260802-fix-p2p-acs-v1-0-a7c5eb64fff6@nvidia.com --- Leon Romanovsky (19): PCI/P2PDMA: Honor device-specific ACS redirection PCI/P2PDMA: Document the TLP attribute assumptions PCI/P2PDMA: Derive routing from directional ACS controls PCI: Reject unreadable ACS controls in isolation checks PCI/P2PDMA: Evaluate ACS controls at the path divergence PCI/P2PDMA: Document directional ACS routing PCI/P2PDMA: Collect the path's ACS controls before deciding PCI/P2PDMA: Answer routing per TLP class PCI/P2PDMA: Route Relaxed Ordering Completions directly PCI/P2PDMA: Reject Translated Requests blocked by Translation Blocking PCI/P2PDMA: Route Translated Requests under Direct Translated P2P PCI/P2PDMA: Log detailed ACS routing diagnostics PCI/P2PDMA: Add KUnit tests for the ACS routing decisions PCI/P2PDMA: Test the ACS P2P routing walk PCI: Add KUnit coverage for ACS isolation checks PCI/P2PDMA: Document TLP-class routing PCI/P2PDMA: Let a client declare that it selects ATS per mapping PCI/P2PDMA: Evaluate the ATS path for clients with ATS enabled PCI/P2PDMA: Test the routing of clients with ATS enabled Documentation/admin-guide/kernel-parameters.txt | 11 +- Documentation/driver-api/pci/p2pdma.rst | 105 ++ drivers/pci/Kconfig | 15 + drivers/pci/Makefile | 1 + drivers/pci/p2pdma.c | 942 +++++++++++++++-- drivers/pci/pci.c | 8 +- drivers/pci/pci.h | 57 ++ drivers/pci/pci_acs_test.c | 1225 +++++++++++++++++++++++ drivers/pci/quirks.c | 8 +- include/linux/pci-p2pdma.h | 12 +- 10 files changed, 2292 insertions(+), 92 deletions(-) --- base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4 change-id: 20260821-fix-p2p-acs-v4-0-e72455e3a261 Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

44 minutes

[PATCH] selftests: dmabuf-heaps: print size_t with %zu

by Sasha Levin

On 32-bit architectures size_t is an unsigned int, and printing it with %ld warns: dmabuf-heap.c:215:43: warning: format '%ld' expects argument of type 'long int', but argument 2 has type 'size_t' {aka 'unsigned int'} [-Wformat=] Use %zu. Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Found with a 32-bit build of the selftests with a 64-bit time_t (gcc 16 and clang 21 with -m32 -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64); KernelCI's 32-bit arm builds show the same warnings. The changed files build without format warnings there now, and the x86_64 builds don't change. The other selftests get the same kind of fix in separate patches. tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c index 1d49df6719198..c65efc088e88d 100644 --- a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c +++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c @@ -212,7 +212,7 @@ static void test_alloc_zeroed(char *heap_name, size_t size) void *p = NULL; char *c; - ksft_print_msg("Testing alloced %ldk buffers are zeroed:\n", size / 1024); + ksft_print_msg("Testing alloced %zuk buffers are zeroed:\n", size / 1024); heap_fd = dmabuf_heap_open(heap_name); /* Allocate and fill a bunch of buffers */ -- 2.53.0

7 hours, 58 minutes

[PATCH] dma-buf: Release input fences in the unwrap merge order test

by Wentao Liang

The merge order test creates an array and a chain as inputs to dma_fence_unwrap_merge(). The merge takes references to the underlying fences but does not consume the input containers. The success path only puts the merged result, leaking both the input array and the outer chain, which owns the inner chain. Put the outer chain after checking the merged result and fall through to the existing array cleanup on success as well as failure. The dma-buf-fence-unwrap KUnit suite passes all 11 tests under UML. Fixes: b1cce631e61f ("dma-buf: add selftest for fence order after merge") Cc: stable(a)vger.kernel.org Assisted-by: DeepSeek-V4.1-Flash and OpenAI Codex Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- drivers/dma-buf/st-dma-fence-unwrap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/st-dma-fence-unwrap.c b/drivers/dma-buf/st-dma-fence-unwrap.c index c5353b36f0e4..8115a721dc88 100644 --- a/drivers/dma-buf/st-dma-fence-unwrap.c +++ b/drivers/dma-buf/st-dma-fence-unwrap.c @@ -437,7 +437,7 @@ static void test_unwrap_merge_order(struct kunit *test) KUNIT_FAIL(test, "Not all fences seen!"); dma_fence_put(a2); - return; + dma_fence_put(c2); error_put_a1: dma_fence_put(a1); -- 2.34.1

16 hours, 3 minutes

[PATCH v3 0/3] dma-buf: dmabuf->file release-time cleanup

by Matt Evans

Hi all, A fix for DMABUF's file-release path, to set dmabuf->file = NULL when the struct file itself is being freed and avoid a stale pointer lingering. Previously it could be assumed that dmabuf->file was always valid until .release was called, but commit 4ab59c3c638c6 ("dma-buf: Move dma_buf_release() from fops to dentry_ops") separated dentry release (calls .release) from file release (can happen before .release). Setting the pointer to NULL clearly delimits the period in which it points to a valid struct file. Raw dmabuf->file access is bad news unless the file is known to have a reference held (for example, during export). A single-threaded problem scenario is a dentry held open (e.g. using O_PATH) but the file closed; .release is not called, so the exporter was unaware that dmabuf->file became stale. Exporter activities using dmabuf->file then led to a UAF. Or, threads racing concurrent access with a file closing. VFIO uses get_file_active(&dmabuf->file), which is a UAF when the pointer goes stale. Alex Mastro has created a VFIO-centric reproducer [1], which shows up with KASAN. To fix, dmabuf->file is either valid or NULL. get_file_active() is then safe and a recommended way to access dmabuf->file without an existing reference. The only possible outcomes are for it to get a reference to the file, to observe a valid pointer but the file in the DEAD state (being closed, fail), or NULL (fail). Patch [3/3] sets the pointer NULL when the file closes, which get_file_active() handles correctly. vmwgfx was identified as doing a problematic dmabuf->file dereference. Although already a UAF, making dmabuf->file = NULL turns it into an oops. So, patch [1/3] correspondingly converts vmwgfx to use get_file_active() too. i915 GVT unsafely dereferences dmabuf->file for a trivial debug printout after the file reference moves to the dmabuf's fd, so patch [2/3] dereferences in the safe window. Added comments to highlight that dmabuf->file could go away before .release, and to use get_file_active() if a reference isn't otherwise already held. Thanks, Matt [1]: https://github.com/opsound/vfio-dmabuf-lab/blob/main/tests/vfio_dmabuf_opat… Changes: v3: - Better comment for struct dma_buf's file (refer to synchronisation against ->release). - Added trivial i915 patch to remove unsafe debug dmabuf->file accesss. v2: https://lore.kernel.org/all/20261009123601.94079-1-matt@ozlabs.org/ "v1" was the single "dma-buf: Annul dmabuf->file on file release" patch: https://lore.kernel.org/all/f8efaabd-c06e-4f04-8cfa-489c148e37ba@ozlabs.org/ Matt Evans (3): drm/vmwgfx: Use get_file_active() for dmabuf->file drm/i915/gvt: Read dmabuf->file only while valid dma-buf: Annul dmabuf->file on file release drivers/dma-buf/dma-buf.c | 21 ++++++++++++++++++--- drivers/gpu/drm/i915/gvt/dmabuf.c | 5 +++-- drivers/gpu/drm/vmwgfx/ttm_object.c | 2 +- include/linux/dma-buf.h | 5 ++++- 4 files changed, 26 insertions(+), 7 deletions(-) -- 2.47.3

1 day, 9 hours

[PATCH v3 0/8] memcg: dma-buf cgroup accounting and charge transfer

by Albert Esteve

Shared-memory allocator services (e.g., Android's gralloc) allocate dma-bufs on behalf of client processes in different cgroups. Today those allocations are charged to the allocator's own cgroup, leaving client cgroups with no visibility into their actual memory consumption and defeating resource limits. This series adds memory cgroup accounting for dma-buf allocations, building on T.J. Mercier's earlier series [1] and incorporating feedback from previous versions and LPC discussions [2]. Patch 1 introduces the MEMCG_DMABUF stat and reserve/commit/cancel and uncharge helpers. Rather than charging at the page level via __GFP_ACCOUNT (which would require every dma-buf exporter to implement charging, and makes cross-cgroup transfer impractical without access to backing pages), we track charges externally on struct dma_buf via a MEMCG_DMABUF stat counter and route all accounting through a single path, removing the __GFP_ACCOUNT flag from system-heap allocations to avoid double counting. Patch 2 adds a charge_fd field to DMA_HEAP_IOCTL_ALLOC, accepting either a pidfd or a cgroupfd to identify the target cgroup at allocation time. If the target cgroup cannot accommodate the charge, the allocation returns -ENOMEM. Patches 3-6 add access control for cross-cgroup charging. Letting userspace decide who to charge needs to be a privileged operation because it has material impact on OOM decission and resource limits. We gate it via LSM hooks for the two charge_fd flavours: security_dma_buf_charge_task() gates the pidfd path (target identified by task credentials) and security_dma_buf_charge_cgroup() gates the cgroupfd path (target identified by cgroup directory label), with SELinux implementations under a dma_buf object class. Patch 7 adds DMA_BUF_IOCTL_XFER_CHARGE, a general ioctl on any dma-buf fd to transfer charges post-allocation. This covers the double-hop allocator case (SurfaceFlinger -> gralloc -> kernel) and works for buffers from any exporter (DRM, V4L2, etc.). A new memcg_account flag is added for dma_buf_export() to ensure that transfer/charge is only applied for buffers backed by reclaimable system memory. If the receiving cgroup lacks capacity for the charge, the ioctl returns -ENOMEM and the original charge is preserved. Patch 8 adds selftests. Known limitations: - Single-owner model: a dma-buf carries one memcg charge regardless of how many processes share it. - Only memcg accounting. CMA heaps would additionally need dmem controller integration. - If a transfer of an uncharged buffer fails, it remains uncharged. The allocator (userspace) is expected to handle this (retry, free, ...). - The LSM hooks are intentionally narrow. Broader cgroup access controls (e.g. for the memfd/kexec handover case [2]) could be a separate effort reusing the same pattern. - Only system heap sets memcg_account today. Other exporters (DRM, V4L2, etc.) can opt in by setting the flag, but are not covered by this series. [1] https://lore.kernel.org/cgroups/20230109213809.418135-1-tjmercier@google.co… [2] https://lpc.events/event/20/contributions/2416/ Signed-off-by: Albert Esteve <aesteve(a)redhat.com> --- Changes in v3: - Split mem_cgroup_charge_dmabuf() into reserve/commit/cancel three-phase API - Extract mem_cgroup_get_from_fd() helper shared by allocate and xfer paths - Rename __padding to flags in struct dma_buf_transfer_charge - Fix UAF race: move mod_memcg_state() before cmpxchg in transfer - Add memcg_account opt-in flag; xfer returns -EOPNOTSUPP if unset - Wrap dma_buf_charge_cgroup hook in #ifdef CONFIG_CGROUPS - Fix TOCTOU in SELinux charge_cgroup xattr length handling - Link to v2: https://lore.kernel.org/r/20261021-v2_20230123_tjmercier_google_com-v2-0-ef… Changes in v2: - Move charge_pid_fd to charge_fd, accepting cgroupfd in addition to pidfd per Christian König. - New DMA_BUF_IOCTL_XFER_CHARGE ioctl for post-allocation charge transfer on any dma-buf, not just dma-heap buffers per Christian König and T.J. Mercier. - Moved __GFP_ACCOUNT removal to patch 1 per Barry Song. - dma-buf charge/uncharge helpers take struct dma_buf * directly to avoid the need for caller to manage size calculations. - Added test_xfer_charge_cgroupfd_self to dmabuf-heap selftests. - Added LSM and SELinux hooks for cgroupfd-based charging. - Rebased to v7.3-rc7. - Link to v1: https://lore.kernel.org/r/20260512-v2_20230123_tjmercier_google_com-v1-0-63… --- Albert Esteve (7): dma-heap: charge dma-buf memory via explicit memcg security: dma-buf: Add dma_buf_charge_task LSM hook security: dma-buf: Add dma_buf_charge_cgroup LSM hook selinux: Restrict cross-cgroup dma-buf charging selinux: Restrict dma-buf direct cgroup charging dma-buf: transfer memcg charges via DMA_BUF_IOCTL_XFER_CHARGE selftests/dmabuf-heaps: Add dma-buf memcg accounting tests T.J. Mercier (1): memcg: Add MEMCG_DMABUF accounting infrastructure Documentation/admin-guide/cgroup-v2.rst | 5 + drivers/dma-buf/dma-buf.c | 46 ++++ drivers/dma-buf/dma-heap.c | 28 +- drivers/dma-buf/heaps/cma_heap.c | 3 +- drivers/dma-buf/heaps/system_heap.c | 22 +- drivers/tee/tee_heap.c | 3 +- include/linux/dma-buf.h | 9 + include/linux/dma-heap.h | 3 +- include/linux/lsm_hook_defs.h | 4 + include/linux/memcontrol.h | 52 ++++ include/linux/security.h | 18 ++ include/uapi/linux/dma-buf.h | 26 ++ include/uapi/linux/dma-heap.h | 7 + mm/memcontrol.c | 192 ++++++++++++++ security/security.c | 34 +++ security/selinux/hooks.c | 44 ++++ security/selinux/include/classmap.h | 1 + tools/testing/selftests/cgroup/Makefile | 2 +- tools/testing/selftests/cgroup/test_memcontrol.c | 290 ++++++++++++++++++++- tools/testing/selftests/dmabuf-heaps/config | 1 + tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 227 +++++++++++++++- tools/testing/selftests/dmabuf-heaps/vmtest.sh | 226 ++++++++++++++++ 22 files changed, 1228 insertions(+), 15 deletions(-) --- base-commit: 24a19b953e2a3d0ea5a8c4951a0ab8f32720c907 change-id: 20260508-v2_20230123_tjmercier_google_com-f44fcfb16530 Best regards, -- Albert Esteve <aesteve(a)redhat.com>

1 day, 10 hours

Re: [PATCH] dma-buf: system_heap: Reject private mappings in system_heap_mmap()

by T.J. Mercier

On Fri, Oct 30, 2026 at 1:44 PM Chris Wiseman <chriswiseman(a)google.com> wrote: > > When commit 381295758792 ("dma-buf: system_heap: Rework system heap to > use sgtables instead of pagelists") stopped using heap_helpers.c and > added a custom system_heap_mmap(), the check rejecting private mappings > was dropped. > > Other exporters and buffer allocators reject private or copy-on-write > mappings in their mmap handlers: cma_heap_mmap() and mmap_udmabuf() > check that VM_SHARED or VM_MAYSHARE is set, and drm_gem_shmem_mmap() > and ttm_bo_mmap_obj() reject vma_is_cow_mapping(vma). > > However, system_heap_mmap() omits this check and calls remap_pfn_range() > even when userspace requests MAP_PRIVATE with PROT_WRITE. As a result, > subsequent CPU writes to a MAP_PRIVATE mapping of a system heap buffer > fault into do_wp_page() -> wp_page_copy(), silently allocating private > anonymous copy-on-write pages whose writes never reach the underlying > system heap buffer pages. > > Reject non-shared mappings in system_heap_mmap() with -EINVAL to match > cma_heap_mmap() and mmap_udmabuf(). > > Fixes: 381295758792 ("dma-buf: system_heap: Rework system heap to use sgtables instead of pagelists") > Cc: stable(a)vger.kernel.org > Signed-off-by: Chris Wiseman <chriswiseman(a)google.com> Reviewed-by: T.J. Mercier <tjmercier(a)google.com> I wonder if we should have this in dma_buf_mmap_internal() though. Any thoughts Sumit or Christian?

1 day, 13 hours

Re: [PATCH v4 00/25] accel/qda: Qualcomm DSP Accelerator driver

by Krzysztof Kozlowski

On 02/11/2026 11:08, Ekansh Gupta wrote: > On 02-11-2026 14:23, Krzysztof Kozlowski wrote: >> On 01/11/2026 23:21, Ekansh Gupta wrote: >>> drivers/accel/qda/qda_soc.c | 66 ++ >>> drivers/accel/qda/qda_soc.h | 61 ++ >>> drivers/misc/Kconfig | 1 + >>> include/uapi/drm/qda_accel.h | 282 +++++++ >>> 33 files changed, 5877 insertions(+), 1 deletion(-) >>> --- >>> base-commit: 7649ba73f9e7e1e04d0b46213e39c79ae09dd55c >>> change-id: 20261102-v4-e8feb321263f >> >> What is happening here? How are we supposed to work with this? >> >> v1: 20260223-qda-firstpost-4ab05249e2cc >> v2: 20260519-qda-series-78c2bf0ed78b >> v2 again: 20260817-qda-v2-78e2d1f10529 >> >> And now completely different one? >> >> This makes the change id completely unusable. b4 diff obviously does not >> work. Any tracking of this does not work. >> >> NAK, really, I already complained internally months ago about such >> practice, so apparently not enough. >> >> Best regards, >> Krzysztof > > Sorry about this. I lost the original b4 branch and re-enrolled the You lost original branch four times. It's not a coincidence, it's not random data loss because then after first loss you would solve the problem. It's a broken workflow. Best regards, Krzysztof

1 day, 14 hours

Re: [PATCH v4 00/25] accel/qda: Qualcomm DSP Accelerator driver

by Krzysztof Kozlowski

On 01/11/2026 23:21, Ekansh Gupta wrote: > drivers/accel/qda/qda_soc.c | 66 ++ > drivers/accel/qda/qda_soc.h | 61 ++ > drivers/misc/Kconfig | 1 + > include/uapi/drm/qda_accel.h | 282 +++++++ > 33 files changed, 5877 insertions(+), 1 deletion(-) > --- > base-commit: 7649ba73f9e7e1e04d0b46213e39c79ae09dd55c > change-id: 20261102-v4-e8feb321263f What is happening here? How are we supposed to work with this? v1: 20260223-qda-firstpost-4ab05249e2cc v2: 20260519-qda-series-78c2bf0ed78b v2 again: 20260817-qda-v2-78e2d1f10529 And now completely different one? This makes the change id completely unusable. b4 diff obviously does not work. Any tracking of this does not work. NAK, really, I already complained internally months ago about such practice, so apparently not enough. Best regards, Krzysztof

1 day, 15 hours

Re: [PATCH v4 21/25] accel/qda: Add Audio protection domain attach and its remote heap

by Krzysztof Kozlowski

On 01/11/2026 23:21, Ekansh Gupta wrote: > > +/* > + * The Audio PD keeps the remote heap across daemon restarts, so only the first > + * attach on a device hands it to the DSP. The lock is held across the attach > + * so that a concurrent one cannot skip the heap while the first is still in > + * flight, and the flag is set only once the DSP has accepted it. > + */ > +static int qda_attach_audio_pd(struct qda_session *session, struct drm_qda_remote_attach *args) > +{ > + struct qda_dev *qdev = session->qda_dev; > + struct qda_static_pd_args sargs = {}; > + char *name; > + int err; > + > + if (strcmp(qdev->dsp_name, "adsp") || !qdev->remote_heap_size) That's value from DTB, so where did you document the ABI? I see such undocumented ABI in multiple places. Usually requirement would be to document it, but not label. Why label 'ADSP' is not correct? Why "Audio DSP" would not be correct? Drop all this label dependency, completely (and do not introduce other names, like node name). Best regards, Krzysztof

1 day, 15 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig