Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

12 participants
3696 discussions

[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>

1 hour, 43 minutes

[PATCH v9 00/14] coco: guest: Add a shared-granule allocator for host-shared memory

by Aneesh Kumar K.V (Arm)

This series tightens the alignment requirements for buffers that are shared between confidential-computing guests and the host, and adds a common allocator for host-shared memory. When a guest runs with private memory, buffers shared with the hypervisor are not only accessed by the guest. They are also accessed by the host kernel, and the host may manage the corresponding shared/private state at a granularity larger than the guest page size. Architectures such as Arm can detect incorrect accesses to Realm physical address space PFNs through GPC faults. However, relying on that as the only line of defence is fragile and can still lead to kernel crashes. The risk is especially visible for shared buffers that are later mmapped into userspace, such as guest_memfd or dma-buf backed allocations. Once userspace can access the mapping, the kernel cannot guarantee that applications will only touch the intended 4K region rather than the whole host page mapped into their address space. Those userspace addresses may also be passed back into the kernel and accessed through the linear map, resulting in a GPC fault. To avoid this, host-shared buffers must satisfy two constraints: - the address must be aligned to the CoCo shared-granule size - the size must be a multiple of that granule size The series adds a common CoCo shared-memory layer for enforcing these constraints. It provides shared-granule geometry and range-validation helpers, byte-oriented private/shared transition helpers, and alloc_cc_shared_pages(). The allocator rounds a request to the architecture shared granule, allocates suitably aligned contiguous pages, transitions the complete allocation to shared state, and returns the transitioned size alongside the page. The corresponding free helper restores the complete allocation to private state before returning it to the buddy allocator. If private state cannot be restored safely, the allocation is deliberately leaked rather than returning potentially shared memory for unrelated use. The series also makes zeroing part of private-to-shared transitions, with each architecture clearing memory at the appropriate point. Callers must therefore initialize shared buffers after the transition; existing contents are not preserved. The shared-granule size defaults to PAGE_SIZE and can be overridden by an architecture. The arm64 CCA changes to discover the host's IPA state change alignment are not included in this series. GIC ITS command queues and tables and the dma-buf system_cc_shared heap use the common allocator. DMA direct, atomic DMA pools and SWIOTLB retain their allocation paths and use the common layout or transition helpers. Restricted DMA pools are checked for shared-granule alignment. Hyper-V users of set_memory_encrypted() and set_memory_decrypted() are not changed by this series. Those paths are not currently used by the arm64 CCA code path, and therefore are not part of the arm64 CCA IPA state change alignment problem addressed here. The series also preallocates GIC ITS VPE L1 tables so shared-memory transitions are performed in a context that may sleep. Notes: * I have not added explicit MAINTAINERS entries for mm/cc_shared.c and include/linux/cc_shared.h, as I am unsure whether we need a separate section for common CoCo-related files. I will add the entries based on feedback. * Codex assisted with implementation, review and series organization. Changes from v8: https://lore.kernel.org/all/20260924100529.1398790-1-aneesh.kumar@kernel.org * Rebase onto the 7.4-rc1 * Move TDX and AMD (including SEV-SNP) zeroing to their finish callbacks so private-to-shared transitions clear the final shared mapping. * Clear __GFP_MOVABLE for shared allocations, which cannot be migrated. * Resolve NUMA_NO_NODE in the common ITS allocation helper to preserve placement for all ITS callers. * Stop SWIOTLB allocation retries when the reduced pool would fall below the shared granule size, avoiding an allocation retry loop. Changes from v7: https://lore.kernel.org/all/20260921144847.501151-1-aneesh.kumar@kernel.org * Add the following new patches: * "irqchip/gic-v3-its: Preallocate VPE L1 tables" * "mm: Assert CoCo shared allocations may sleep" * "mm: Zero memory during shared memory transitions" * Drop the arm64 RHI and shared granule size patches so that the series can be rebased on top of upstream to enable Shashiko review. Changes from v6: https://lore.kernel.org/all/20260904103452.1197239-1-aneesh.kumar@kernel.org * Add a common allocator and geometry/transition helpers for CoCo host-shared memory. * Convert GIC ITS, dma-direct, atomic DMA pools, and the dma-buf system_cc_shared heap to the common allocator. * Limit dma-buf scatterlist entries to the requested buffer size so rounded backing is not exposed to importers. Changes from v5: https://lore.kernel.org/all/20260706060432.1375570-1-aneesh.kumar@kernel.org * Rebased to latest kernel * Drop patch arm64: realm: Move Realm memory encryption ops to RSI code Changes from v4: https://lore.kernel.org/all/20260427063108.909019-1-aneesh.kumar@kernel.org * Rename the helpers to use CoCo terminology (mem_cc_shared_granule_size() / mem_cc_align_to_shared_granule() instead of mem_decrypt_granule_size() / mem_decrypt_align()). * Use __DMA_ATTR_ALLOC_CC_SHARED to pass CoCo shared allocation requirements down to CMA-based allocation helpers. * Add validation for restricted DMA pools to reject pools that are not aligned to the shared granule size. * Add dma-buf system heap handling for cc-shared buffers. * Split the previous combined DMA/SWIOTLB/ITS change into smaller subsystem patches covering ITS, DMA direct, SWIOTLB, restricted DMA pools, dma-buf system heap, and arm64 Realm support. * Rework arm64 Realm support by moving Realm memory encryption ops into RSI code and exposing the CCA shared granule size through arm64_mem_crypt_ops. Changes from v3: https://lore.kernel.org/all/20260309102625.2315725-1-aneesh.kumar@kernel.org * Fix build error reported by kernel test robot <lkp(a)intel.com> Changes from v2: https://lore.kernel.org/all/20251221160920.297689-1-aneesh.kumar@kernel.org * Rebase to latest kernel * Consider swiotlb always decrypted and don't align when allocating from swiotlb. Changes from v1: * Rename the helper to mem_encrypt_align * Improve the commit message * Handle DMA allocations from contiguous memory * Handle DMA allocations from the pool * swiotlb is still considered unencrypted. Support for an encrypted swiotlb pool is left as TODO and is independent of this series. Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Baoquan He <baoquan.he(a)linux.dev> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Pasha Tatashin <pasha.tatashin(a)soleen.com> Cc: Pratyush Yadav <pratyush(a)kernel.org> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: Joerg Roedel (AMD) <joro(a)8bytes.org> Cc: Marc Zyngier <maz(a)kernel.org> Cc: Marek Szyprowski <m.szyprowski(a)samsung.com> Cc: Robin Murphy <robin.murphy(a)arm.com> Cc: Steven Price <steven.price(a)arm.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> Cc: Thomas Gleixner <tglx(a)kernel.org> Cc: Will Deacon <will(a)kernel.org> Cc: Russell King <linux(a)armlinux.org.uk> Cc: Benjamin Gaignard <benjamin.gaignard(a)collabora.com> Cc: Brian Starkey <Brian.Starkey(a)arm.com> Cc: John Stultz <jstultz(a)google.com> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Radu Rendec <radu(a)rendec.net> Cc: "T.J. Mercier" <tjmercier(a)google.com> Cc: Madhavan Srinivasan <maddy(a)linux.ibm.com> Cc: Michael Ellerman <mpe(a)ellerman.id.au> Cc: Nicholas Piggin <npiggin(a)gmail.com> Cc: Christophe Leroy (CS GROUP) <chleroy(a)kernel.org> Cc: Ritesh Harjani (IBM) <ritesh.list(a)gmail.com> Cc: Shrikanth Hegde <sshegde(a)linux.ibm.com> Cc: Alexander Gordeev <agordeev(a)linux.ibm.com> Cc: Gerald Schaefer <gerald.schaefer(a)linux.ibm.com> Cc: Heiko Carstens <hca(a)linux.ibm.com> Cc: Vasily Gorbik <gor(a)linux.ibm.com> Cc: Christian Borntraeger <borntraeger(a)linux.ibm.com> Cc: Sven Schnelle <svens(a)linux.ibm.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: x86(a)kernel.org Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Kiryl Shutsemau <kas(a)kernel.org> Cc: Rick Edgecombe <rick.p.edgecombe(a)intel.com> Cc: K. Y. Srinivasan <kys(a)microsoft.com> Cc: Haiyang Zhang <haiyangz(a)microsoft.com> Cc: Wei Liu <wei.liu(a)kernel.org> Cc: Dexuan Cui <decui(a)microsoft.com> Cc: Long Li <longli(a)microsoft.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Vitaly Kuznetsov <vkuznets(a)redhat.com> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: dri-devel(a)lists.freedesktop.org Cc: iommu(a)lists.linux.dev Cc: linaro-mm-sig(a)lists.linaro.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-media(a)vger.kernel.org Cc: linux-mm(a)kvack.org Cc: kvmarm(a)lists.linux.dev Cc: linux-arm-kernel(a)lists.infradead.org Cc: patches(a)lists.linux.dev Aneesh Kumar K.V (Arm) (14): mm: Add an allocator for CoCo shared memory mm: Zero memory during shared memory transitions irqchip/gic-v3-its: Resolve the default NUMA node explicitly irqchip/gic-v3-its: Allocate shared tables using CoCo shared memory allocator dma-contiguous: Derive shared alignment from DMA attributes dma-pool: Allocate CoCo atomic pools using CoCo shared memory allocator dma-direct: Align CoCo shared DMA allocations to the shared granule size swiotlb: Align shared IO TLB pools to the shared granule size swiotlb: Reject misaligned restricted DMA pools for CoCo guests dma-buf: system_heap: Limit scatterlist entries to the buffer size dma-buf: system_heap: Allocate shared buffers using CoCo shared memory allocator swiotlb: Make rounded shared pool capacity allocatable mm: Assert CoCo shared allocations may sleep irqchip/gic-v3-its: Preallocate VPE L1 tables arch/arm/mm/dma-mapping.c | 5 +- arch/powerpc/platforms/pseries/svm.c | 2 + arch/s390/mm/init.c | 3 + arch/x86/coco/tdx/tdx.c | 3 + arch/x86/hyperv/hv_init.c | 6 +- arch/x86/hyperv/ivm.c | 4 + arch/x86/kernel/kvmclock.c | 6 +- arch/x86/mm/mem_encrypt_amd.c | 4 + drivers/dma-buf/heaps/system_heap.c | 128 +++++----- drivers/firmware/arm_rmm/rsi.c | 4 + drivers/hv/connection.c | 41 ++- drivers/hv/hv.c | 11 +- drivers/hv/hv_common.c | 2 - drivers/iommu/dma-iommu.c | 2 +- drivers/irqchip/irq-gic-v3-its.c | 152 +++++++++--- drivers/irqchip/irq-gic-v3.c | 4 +- drivers/virt/coco/pkvm-guest/arm-pkvm-guest.c | 3 + include/linux/cc_shared.h | 39 +++ include/linux/dma-map-ops.h | 9 +- include/linux/irqchip/arm-gic-v3.h | 3 +- kernel/dma/contiguous.c | 41 ++- kernel/dma/direct.c | 73 ++++-- kernel/dma/ops_helpers.c | 2 +- kernel/dma/pool.c | 27 +- kernel/dma/swiotlb.c | 87 +++++-- kernel/kexec_file.c | 3 +- mm/Makefile | 1 + mm/cc_shared.c | 233 ++++++++++++++++++ 28 files changed, 693 insertions(+), 205 deletions(-) create mode 100644 include/linux/cc_shared.h create mode 100644 mm/cc_shared.c base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4 prerequisite-patch-id: 1d4a2fa9dc0f4b560e55f419d23835f0a9fbe485 -- 2.43.0

2 hours, 11 minutes

[PATCH v4 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/cancel and uncharge helpers in mm/memcontrol.c Patch 2 wires up the charging policy: dma_buf_export() stores exp_info.memcg and updates the stat, a new charge_fd field in DMA_HEAP_IOCTL_ALLOC accepts a pidfd or cgroupfd to identify the target cgroup, and __GFP_ACCOUNT is removed from system-heap allocations to avoid double counting. Patch 3 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.). Charging is gated by dmabuf->memcg being set at export time, ensuring that transfer is only applied for buffers backed by system memory where size reflects actual bytes. If the receiving cgroup lacks capacity for the charge, the ioctl returns -ENOMEM and the original charge is preserved. Patches 4-7 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 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, the buffer remains charged to the original cgroup. 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 exp_info.memcg today. Other exporters (DRM, V4L2, etc.) can opt in by setting it, but are not covered by this series. - Related to the above: lazy backing-store allocation is not supported. This can be extended later, e.g., by adding a flag on the dma-buf struct for explicitly marking when memory is committed. [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 v4: - Remove memcg_account flag; exp_info.memcg != NULL is the opt-in - Centralize memcg bookkeeping in dma_buf_export() - Drop mem_cgroup_commit_dmabuf() - Make mem_cgroup_transfer_charge() generic (not dma-buf specific) - Add EXPORT_SYMBOL_GPL for reserve/cancel (system_heap is tristate) - Reorder: move xfer ioctl before LSM patches - Serialize dmabuf->memcg updates with the dma-buf resv lock instead of cmpxchg - Link to v3: https://lore.kernel.org/r/20261027-v2_20230123_tjmercier_google_com-v3-0-78… 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 dma-buf: transfer memcg charges via DMA_BUF_IOCTL_XFER_CHARGE 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 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 | 50 ++++ drivers/dma-buf/dma-heap.c | 28 +- drivers/dma-buf/heaps/cma_heap.c | 3 +- drivers/dma-buf/heaps/system_heap.c | 21 +- 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 | 47 ++++ include/linux/security.h | 18 ++ include/uapi/linux/dma-buf.h | 26 ++ include/uapi/linux/dma-heap.h | 7 + mm/memcontrol.c | 176 +++++++++++++ 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, 1210 insertions(+), 15 deletions(-) --- base-commit: 24a19b953e2a3d0ea5a8c4951a0ab8f32720c907 change-id: 20260508-v2_20230123_tjmercier_google_com-f44fcfb16530 Best regards, -- Albert Esteve <aesteve(a)redhat.com>

5 hours, 5 minutes

Re: [PATCH 1/1] i2c: use dmaengine_get_dma_device() instead of chan->device->dev

by Wolfram Sang

Hi Frank, On Tue, Nov 03, 2026 at 04:26:54PM -0500, Frank.Li(a)oss.nxp.com wrote: > From: Frank Li <Frank.Li(a)nxp.com> > > Replace direct dma_chan::device::dev access with the proper > dmaengine_get_dma_device() for consumer API. > > chan->device->dev is not always the device used for DMA mapping. Some DMA > engines support per-channel IOMMU mappings, so different channels may use > different DMA devices. dmaengine_get_dma_device() returns the correct > device for each channel. > > This also prepares for making the DMA engine provider data structures > private. DMA consumers should not access DMA engine internals directly. Thanks for this, looks useful. > - dma_addr = dma_map_single(chan->device->dev, buf, len, dir); > - if (dma_mapping_error(chan->device->dev, dma_addr)) { > + dma_addr = dma_map_single(dmaengine_get_dma_device(chan), buf, len, dir); > + if (dma_mapping_error(dmaengine_get_dma_device(chan), dma_addr)) { > dev_dbg(dev, "dma map failed, using PIO\n"); I think we should populate a dma_dev-variable here and reuse it instead of calling dmaengine_get_dma_device() twice. Happy hacking, Wolfram

6 hours, 1 minute

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>

19 hours, 7 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

1 day, 2 hours

[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

1 day, 10 hours

[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

2 days, 3 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>

2 days, 4 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?

2 days, 7 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig