Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

14 participants
3627 discussions

Re: [PATCH v2 05/15] iommu: Add QDA compute context bank bus to iommu_buses

by Jason Gunthorpe

On Mon, Aug 17, 2026 at 10:17:40AM +0530, Ekansh Gupta wrote: > Register the QDA compute context bank bus (qda-compute-cb) with the > IOMMU subsystem by adding it to the iommu_buses[] array. > > The QDA driver creates synthetic devices on this bus to represent > IOMMU context banks (CBs). Each CB device needs its own IOMMU domain > so that the DSP memory manager can enforce per-session address space > isolation. Without this registration, the IOMMU subsystem does not > probe CB devices for IOMMU groups and of_dma_configure() in the bus > dma_configure callback has no IOMMU domain to attach to. I didn't notice a clear explanation of the proposed DT schema for this But it looks awfully similar to the other driver that was creating a kernel synthetic bus for actual real HW, that wasn't well liked. What is this for? Why can't you have a normal DT binding for the iommu with normal devices? Jason

1 month, 3 weeks

Re: [PATCH v2 05/15] iommu: Add QDA compute context bank bus to iommu_buses

by Joerg Roedel (AMD)

On Mon, Aug 17, 2026 at 10:17:40AM +0530, Ekansh Gupta wrote: > Register the QDA compute context bank bus (qda-compute-cb) with the > IOMMU subsystem by adding it to the iommu_buses[] array. > > The QDA driver creates synthetic devices on this bus to represent > IOMMU context banks (CBs). Each CB device needs its own IOMMU domain > so that the DSP memory manager can enforce per-session address space > isolation. Without this registration, the IOMMU subsystem does not > probe CB devices for IOMMU groups and of_dma_configure() in the bus > dma_configure callback has no IOMMU domain to attach to. > > Assisted-by: Claude:claude-sonnet-5 > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov(a)oss.qualcomm.com> > Signed-off-by: Ekansh Gupta <ekansh.gupta(a)oss.qualcomm.com> > --- > drivers/iommu/iommu.c | 4 ++++ > 1 file changed, 4 insertions(+) Acked-by: Joerg Roedel <joerg.roedel(a)amd.com>

1 month, 3 weeks

[PATCH v5 0/9] vfio/pci: Add mmap() for DMABUFs

by Matt Evans

Hi all, The goal of this series is to enable userspace driver designs that use VFIO to export DMABUFs representing subsets of PCI device BARs, and "vend" those buffers from a primary process to other subordinate processes by fd. These processes then mmap() the buffers and their access to the device is isolated to the exported ranges. This is an improvement on sharing the VFIO device fd to subordinate processes, which would allow unfettered access. This is achieved by enabling mmap() of vfio-pci DMABUFs, passed by fd to subordinate processes. Second, a new revocation mechanism is added to allow the primary process to forcibly revoke access to previously-shared BAR spans, even if the subordinate processes haven't cleanly exited. (The related topic of safe delegation of iommufd control to the subordinate processes is not addressed here, and is follow-up work.) The background/rationale is covered in more detail in the RFC cover letters. Feedback from the RFCs requested that, instead of creating DMABUF-specific vm_ops and .fault paths, to go the whole way and migrate the existing VFIO PCI BAR mmap() to be backed by a DMABUF too, resulting in a common vm_ops and fault handler for mmap()s of both the VFIO device and explicitly-exported DMABUFs. This will help future iommufd emulation of VFIO Type1 peer-to-peer, making it easier to get a DMABUF for a VFIO BAR as a DMA target. mmap() conversion to use DMABUF underneath has been done for vfio-pci, but not sub-drivers: nvgrace-gpu's mmap() override path is unchanged; I kept this out of scope for now not least because I don't have a thorough test setup for this system. I would prefer to help the nvgrace-gpu maintainers enable BAR mmap() DMABUFs themselves. Notes on patches ================ PCI/P2PDMA: Split pool-related cleanup out of pci_p2pdma_release() PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE Later in the series, vfio-pci's mmap() is going to depend on pcim_p2pdma_provider() which depended on CONFIG_PCI_P2PDMA, which in turn depended on ZONE_DEVICE. That isn't available on 32-bit and some archs, because they lack MEMORY_HOTPLUG and friends. VFIO does _not_ require actual P2P to be present for basic mmap() functionality, only for the optional CONFIG_DMA_SHARED_BUFFER feature. These split out p2pdma_core.c under CONFIG_PCI_P2PDMA_CORE (which currently contains pcim_p2pdma_provider()), and an optional CONFIG_PCI_P2PDMA which depends on ZONE_DEVICE etc. providing P2P functionality in the existing p2pdma.c. The first splits out pool cleanup from the release path, and the second does the refactor/code move to the new file. vfio/pci: Add a helper to look up PFNs for DMABUFs vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA The first adds a DMABUF VMA fault handler helper to determine arbitrary-sized PFNs from ranges in DMABUF. The second refactors DMABUF export for use by the existing export feature, and adds a helper that creates a DMABUF corresponding to a VFIO BAR mmap() request. vfio/pci: Convert BAR mmap() to use a DMABUF The vfio-pci core mmap() creates a DMABUF with the helper above, and the vm_ops fault handler uses the other helper to resolve the fault. Because this depends on DMABUF structs/code, CONFIG_VFIO_PCI_CORE needs to depend on CONFIG_DMA_SHARED_BUFFER. The CONFIG_VFIO_PCI_DMABUF still conditionally enables the export support code. NOTE: The user mmap()s a device fd, but the resulting VMA's vm_file becomes that of the DMABUF. The DMABUF takes ownership of the device file and put()s it on release, which maintains the existing behaviour of a VMA keeping the VFIO device open. BAR zapping then happens via the existing vfio_pci_dma_buf_move() path, which now needs to unmap PTEs in the DMABUF's address_space. vfio/pci: Provide a user-facing name for BAR mappings There was a request for decent debug naming in /proc/<pid>/maps etc. comparable to the existing VFIO names: since the VMAs are DMABUFs, they have a "dmabuf:" prefix and can't be 100% identical to before. This is a user-visible change, but this patch at least now gives us extra info on the BDF & BAR being mapped. vfio/pci: Clean up BAR zap and revocation In general (see NOTE!) the vfio_pci_zap_bars() is now obsolete, since it unmaps PTEs in the VFIO device address_space which is now unused. This consolidates all calls (e.g. around reset) with the neighbouring vfio_pci_dma_buf_move()s into new functions, to revoke/unrevoke (making the steps clearer). NOTE: Because drivers can use their own vm_ops and override .mmap, the core must conservatively assume an overridden .mmap might still add PTEs to the VFIO device address_space and therefore still does the zap. A new flag, zap_bars_on_revoke, enables the zap when .mmap is overridden. A driver that does not need the zap can clear this to opt-out, e.g. if the driver calls down to the common mmap (and so uses DMABUFs). hisi-acc-vfio-pci does just this, and thus sets the opt-out flag. vfio/pci: Support mmap() of a VFIO DMABUF Adds mmap() for a DMABUF fd exported from vfio-pci. It was a goal to keep the VFIO device fd lifetime behaviour unchanged with respect to the DMABUFs. An application can close all device fds, and this will revoke/clean up all DMABUFs; then, no mappings or other access can be performed. When enabling mmap() of the DMABUFs, this means access through the VMA is also revoked. This complicates the fault handler because whilst the DMABUF exists, it has no guarantee that the corresponding VFIO device is still alive. Adds synchronisation ensuring the vdev is available before vdev->memory_lock is touched; this holds the device registration so that even if the buffer has been cleaned up, vdev hasn't been freed and so the lock can be safely taken. vfio/pci: Permanently revoke a DMABUF on request This is mostly a rename of `revoked` to an enum, `status`, and adding a third state for a buffer: usable, revoked temporary, revoked permanent. A new VFIO feature is added, VFIO_DEVICE_FEATURE_DMA_BUF_REVOKE, which takes a DMABUF (exported from the same device) and permanently revokes it. Thus a userspace driver can guarantee any downstream consumers of a shared fd are prevented from accessing a BAR range, and that range can be reused. NOTE: This might block userspace, waiting on importers to detach. The code doing revocation in vfio_pci_dma_buf_move() is moved, to a common function for use by ..._move() and this new feature. NOTE: See changelog, by request v4 added a condition to the existing code to elide the unnecessary invalidation/sync on the un-revoke path.) NOTE: Previous versions contained an additional feature patch, "vfio/pci: Add mmap() attributes to DMABUF feature". This has been dropped in v5 because: - The mechanism simply set vma->vm_page_prot. This would be sufficient for arm64 and other architectures. - However, (locally-run claude-opus-4-8) Sashiko flagged that, on x86, additional memtype handling is required to set up the PAT. Without this, the memtype is returned back to UC- by pfnmap_setup_cachemode() upon PTE creation. Most other sources of userspace WC mappings create PTEs eagerly with e.g. io_remap_pfn_range() which memtype_reserve() WC for the range. Getting them with lazy-fault used by vfio-pci is more complicated (e.g. perhaps registering WC for BARs with PAT/MTRRs, and deciding how to deal with aliasing...). Since this feature is not critical for this series to be useful, I've decided for now to drop it in favour of a simpler series now and revisiting this separ*ately. Testing ======= (The [RFC ONLY] userspace test program, for QEMU edu-plus, can be found in the GitHub branch below. It at least illustrates how the export, map, revoke, and close semantics interoperate.) This code has been tested in mapping DMABUFs of single/multiple ranges from multiple BARs, aliasing mmap()s, aliasing ranges across DMABUFs, vm_pgoff > 0, revocation, shutdown/cleanup scenarios, and hugepage mappings. No regressions observed on the VFIO selftests, or on our internal vfio-pci applications. VFIO on i386 has been build-tested. Dear Reviewers, =============== I was grateful for the reviews and Reviewed-Bys on previous versions. Thanks; I've added some Reviewed-Bys/Acks. I have NOT included your tags where the patch has materially changed after your review (or where requested changes ended up more than super-trivial). I hope that's okay. End === This is based on v7.2-rc3. These commits are on GitHub for easier browsing, along with "[RFC ONLY] selftests: vfio: Add standalone vfio_dmabuf_mmap_test": https://github.com/metamev/linux/compare/v7.2-rc3...dev/mev/vfio-dmabuf-mma… Thanks for reading, Matt ================================================================================ Changelog: v5: - Rebased on 7.2-rc3 - Dropped the memattr/WC feature (see explanation above). - "vfio/pci: Convert BAR mmap() to use a DMABUF": Fixed a potentially-nasty bug (which (locally-run) Sashiko found!) whereby the unmap_mapping_range() performed in cleanup was passed a range up from offset zero for the DMABUF size. Initially this was how all DMABUFs were created and an appropriate zap, but a new version kept the VFIO region index encoded in the offset -- for BAR > 0 the unmap span would then mismatch. Instead, pass size 0 to mean an "all" range. Because the goal is to shoot down everything relating to one DMABUF and the address_space can only contain things relating to that DMABUF, this is equivalent and has the bonus of never failing to match mappings... Praan, Kevin, I kept your R-Bs on this fix. - The revoke patch converts vfio_pci_dma_buf_cleanup()'s priv->vdev = NULL to a WRITE_ONCE, corresponding to the revoke function's READ_ONCE (performed to test that the VFIO and DMABUF are related). - Clarified the VFIO_DEVICE_FEATURE_DMA_BUF_REVOKE UAPI comments, documenting previously-missing error cases and their reasons. v4: https://lore.kernel.org/all/20260701171245.90111-1-matt@ozlabs.org/ v3: https://lore.kernel.org/all/20260610154327.37758-1-matt@ozlabs.org/ v2: https://lore.kernel.org/all/20260527102319.100128-1-mattev@meta.com/ v1: https://lore.kernel.org/kvm/20260416131815.2729131-1-mattev@meta.com/ RFCv2: https://lore.kernel.org/kvm/20260312184613.3710705-1-mattev@meta.com/ RFCv1: https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/ Tech topic: https://lore.kernel.org/linux-iommu/20250918214425.2677057-1-amastro@fb.com/ Matt Evans (9): PCI/P2PDMA: Split pool-related cleanup out of pci_p2pdma_release() PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE vfio/pci: Add a helper to look up PFNs for DMABUFs vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA vfio/pci: Convert BAR mmap() to use a DMABUF vfio/pci: Provide a user-facing name for BAR mappings vfio/pci: Clean up BAR zap and revocation vfio/pci: Support mmap() of a VFIO DMABUF vfio/pci: Permanently revoke a DMABUF on request MAINTAINERS | 2 +- drivers/pci/Kconfig | 5 + drivers/pci/Makefile | 1 + drivers/pci/p2pdma.c | 113 +--- drivers/pci/p2pdma.h | 29 + drivers/pci/p2pdma_core.c | 122 +++++ drivers/vfio/pci/Kconfig | 5 +- drivers/vfio/pci/Makefile | 3 +- .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 8 + drivers/vfio/pci/vfio_pci_config.c | 30 +- drivers/vfio/pci/vfio_pci_core.c | 210 +++++-- drivers/vfio/pci/vfio_pci_dmabuf.c | 515 +++++++++++++++--- drivers/vfio/pci/vfio_pci_priv.h | 53 +- include/linux/pci-p2pdma.h | 24 +- include/linux/pci.h | 2 +- include/linux/vfio_pci_core.h | 1 + include/uapi/linux/vfio.h | 25 + 17 files changed, 875 insertions(+), 273 deletions(-) create mode 100644 drivers/pci/p2pdma.h create mode 100644 drivers/pci/p2pdma_core.c -- 2.50.1 (Apple Git-155)

1 month, 4 weeks

Re: [PATCH v2 0/5] accel/amdxdna: honour the SYNC_BO range

by Christian König

On 8/12/26 01:13, Taimuraz Kaitmazov wrote: > SYNC_BO carries an offset and a size, but amdxdna_flush_bo() honours them > only on the vmap path. An imported BO is tested for first and flushes its > whole scatterlist, Absolutely clear NAK to that from a DMA-buf maintainer side. Flushing on imported scatterlist of a DMA-buf is a really big NO-GO. If DMA-buf imports are used with the device then the device needs to be able to coherently access the underlying memory. In other words you *CAN'T* call drm_clflush_pages() on imported memory. Regards, Christian. > so a sync costs what the BO is worth rather than what > the caller asked to maintain: on npu4 an imported 64 MiB BO cost 1056 us > to sync at every size from 4 KiB up. Patch 5 reorders the arms so the > vmap path is tried first, and indexes the page-array fallback from the > requested offset. > > The four before it are the ground that has to be solid first. Patch 1 > refuses an I/O memory mapping, which the driver currently stores as if it > were an ordinary kernel address. Patch 2 adds a probe that does not log, > so patch 5 does not make an exporter without a vmap op print on every > ioctl. Patches 3 and 4 fix two ways the ioctl mishandles its own range: a > zero length reaching drm_clflush_virt_range(), and an offset and size > added to the BO address without an overflow check, one level above a > function that checks the same arithmetic. All four stand on their own and > can be taken separately; only patch 5 depends on them. > > v1 did not reach dri-devel, so this is the first version visible there. > It is on lore via the other lists it was copied to: > https://lore.kernel.org/lkml/20260811204556.875037-1-taimuraz@kaitmazov.com/ > > Changes in v2: > - patch 2: take the device from the GEM object rather than abo->client. > amdxdna_gem_obj_close() clears that pointer under abo->lock, which the > pre-split code held across the log and the split did not. > - new patch 3: return early from a zero-length flush. > - new patch 4: check the sync range for overflow on a device BO. > - patch 5: say why the persistent mapping adds no pin. > > The measurements in patch 5 were taken with the equivalent change in > AMD's out-of-tree xdna-driver, where this merged as #1541. That version > and this one differ only in a page-array fallback mainline has no field > for, reached when the mapping fails and the BO is neither imported nor > shmem backed, and in the name of the mapping helper. The flush and the > helper are otherwise identical. This version is compile-tested; it has > not been booted. > > Patch 1 is from inspection rather than a reproducer. The exporter I can > test against is amdgpu, and amdgpu is the case that cannot reach it: it > implements .pin, so a non peer to peer attachment like this driver's > forces the buffer to GTT before anything maps it. Reproducing it needs a > GPU whose exporter has no .pin, which I do not have paired with an NPU > here. > > Taimuraz Kaitmazov (5): > accel/amdxdna: refuse an I/O memory mapping of an imported BO > accel/amdxdna: add a quiet variant of amdxdna_gem_vmap() > accel/amdxdna: return early from a zero-length flush > accel/amdxdna: check the sync range for overflow on a device BO > accel/amdxdna: flush only the requested range in amdxdna_flush_bo > > drivers/accel/amdxdna/amdxdna_gem.c | 66 +++++++++++++++++++++-------- > 1 file changed, 49 insertions(+), 17 deletions(-) > > -- > 2.55.0 >

2 months

Re: [PATCH RFC 3/5] mm/slab, kmemleak: handle kmemleak freeing in kfree_nolock()

by Catalin Marinas

On Fri, Aug 07, 2026 at 03:50:29PM +0200, Vlastimil Babka (SUSE) wrote: > Kmemleak handling is one of the reasons why kfree_nolock() cannot > currently handle kmalloc() objects, because calling kmemleak_free() > would involve spinning on its internal raw spinlocks. > > Kmemleak is a debugging mechanism so we could simply defer all > kfree_nolock() to irq_work if it's enabled, and eat the extra cost. But > that would be unnecessary pessimistic. We expect kfree_nolock() will be > still mostly called on objects from kmalloc_nolock() that are not > registered in kmemleak so they still don't need any deferred freeing. > > Thus introduce kmemleak_may_need_free() that can check if the object is > registered. This is done using __lookup_object() performed under a > raw_spin_trylock_irqsave(), which is safe to attempt from kfree_nolock() > (except from a NMI on a !CONFIG_SMP system). When that trylock fails or > can't be attempted, we however must assume the object might be > registered, and defer the freeing. The only risk is during kmemleak scanning when kmemleak_lock is repeatedly held by scan_block() even for minutes. There may be some timing where most kfree_nolock() deferred during such scanning. Not sure it matters much though, unless the kfree_nolock() use becomes widely spread. If it becomes problematic, we could add a new RCU-protected hash that's searchable for this specific case (we can't remove the rbtree as we need interval searching in general). Otherwise the kmemleak changes look ok to me. Reviewed-by: Catalin Marinas <catalin.marinas(a)arm.com> > void kfree_nolock(const void *object) > { > @@ -6844,9 +6848,23 @@ void kfree_nolock(const void *object) > */ > kasan_slab_free(s, x, false, false, /* skip quarantine */true); Not related to kmemleak but I noticed this call here: if we relax kfree_nolock() for any slab objects, would the above poison SLAB_TYPESAFE_BY_RCU objects while they are still in use? I guess we should not allow such slabs on this path. Sashiko had some comments as well, I haven't gone through them but it also mentioned SLAB_TYPESAFE_BY_RCU on another patch. -- Catalin

2 months

Re: [PATCH v4 03/10] dt-bindings: gpu: host1x: Document memory-regions for NVDEC

by Rob Herring (Arm)

On Fri, 07 Aug 2026 17:54:23 +0200, Thierry Reding wrote: > From: Thierry Reding <treding(a)nvidia.com> > > The video protection region is a reserved memory region that can be used > for secure video playback. NVDEC can access this region to decode images > into securely. > > Signed-off-by: Thierry Reding <treding(a)nvidia.com> > --- > .../devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml | 8 ++++++++ > 1 file changed, 8 insertions(+) > Reviewed-by: Rob Herring (Arm) <robh(a)kernel.org>

2 months

Re: [PATCH v4 02/10] dt-bindings: display: tegra: Document memory regions

by Rob Herring (Arm)

On Fri, 07 Aug 2026 17:54:22 +0200, Thierry Reding wrote: > From: Thierry Reding <treding(a)nvidia.com> > > Add the memory-region and memory-region-names properties to the bindings > for the display controllers and the host1x engine found on various Tegra > generations. These memory regions are used to access firmware-provided > framebuffer memory as well as the video protection region. > > Signed-off-by: Thierry Reding <treding(a)nvidia.com> > --- > Changes in v4: > - typofix > > Changes in v3: > - document properties for VIC > --- > .../devicetree/bindings/display/tegra/nvidia,tegra124-vic.yaml | 8 ++++++++ > .../devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml | 10 ++++++++++ > .../devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml | 10 +++++++++- > .../bindings/display/tegra/nvidia,tegra20-host1x.yaml | 7 +++++++ > 4 files changed, 34 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring (Arm) <robh(a)kernel.org>

2 months

[PATCH] kselftests: dmabuf-heaps: Open heap device files O_RDONLY

by T.J. Mercier

Write permissions on the /dev/dma_heap/* device files are not required to issue ioctls and allocate dmabufs. Applications should be opening these file as O_RDONLY. The BPF dmabuf_iter selftest already does this. [1] Users are pointing to these selftests as examples of how use dmabuf, and encountering permission errors on systems where write permissions are not available on /dev/dma_heap/*. Apply the principle of least privilege to selftests which open dmabuf heaps by removing the write access mode and using O_RDONLY for the open() instead. The same is true for the vgem test using /dev/dri/card. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/too… Signed-off-by: T.J. Mercier <tjmercier(a)google.com> --- tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c index fc9694fc4e89..45b420e37c97 100644 --- a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c +++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c @@ -48,7 +48,7 @@ static int open_vgem(void) snprintf(name, 80, "%s%u", drmstr, i); - fd = open(name, O_RDWR); + fd = open(name, O_RDONLY); if (fd < 0) continue; @@ -96,7 +96,7 @@ static int dmabuf_heap_open(char *name) if (ret < 0) ksft_exit_fail_msg("snprintf failed! %d\n", ret); - fd = open(buf, O_RDWR); + fd = open(buf, O_RDONLY); if (fd < 0) ksft_exit_fail_msg("open %s failed: %s\n", buf, strerror(errno)); base-commit: 9a11db68872055e6ead919bad04d6330851c522d -- 2.55.0.679.g6767b8d81c-goog

2 months

Re: [PATCH v6 0/4] dma-buf: fix fd leak when copy_to_user() fails after fd_install()

by Sumit Semwal

Hello Baineng, On Fri, 7 Aug 2026 at 15:41, Baineng Shou <shoubaineng(a)gmail.com> wrote: > > Several drivers call dma_buf_fd() — which internally calls fd_install() > — before copy_to_user() returns the fd number to userspace. If > copy_to_user() fails, the fd is already published in the caller's fd > table but the ioctl returns an error, so userspace never learns the fd > number. Worse, the window between fd_install() and copy_to_user() > allows other threads to observe and manipulate the fd (dup, close, > SCM_RIGHTS), making any "close it on the failure path" fix unsafe. > > The fix is to split the allocation into three steps: reserve an fd with > get_unused_fd_flags() (not yet visible to other threads), do > copy_to_user(), and only then publish the fd with fd_install() via the > new dma_buf_fd_install() helper. On copy_to_user() failure, > put_unused_fd() + dma_buf_put() cleanly unwind with no user-visible > side effects. > > Patch 1 introduces dma_buf_fd_install() in dma-buf.c (wrapping > fd_install() together with the DMA_BUF_TRACE call to preserve export > tracing) and applies the fix to dma-heap. > > Patch 2 applies the same fix to fastrpc, which even had a comment > acknowledging the problem could not be fixed before. > > Patch 3 replaces the bare fd_install() in drm_gem_prime_handle_to_fd() > with dma_buf_fd_install() to restore tracepoint coverage for DRM PRIME > exports (suggested by Christian König). > > Patch 4 adds a selftest to tools/testing/selftests/dmabuf-heaps/ that > reproduces the fd-leak scenario (mprotect flip before the ioctl) and > verifies the fd count is unchanged after a failed ioctl (suggested by > Sumit Semwal). Thank you for the series - please feel free to add my Acked-by: Sumit Semwal <sumit.semwal(a)linaro.org> > > v1: https://lore.kernel.org/dri-devel/20260703080922.1838362-1-shoubaineng@gmai… > v2: https://lore.kernel.org/dri-devel/20260710105430.3059661-1-shoubaineng@gmai… > v3: https://lore.kernel.org/dri-devel/20260714114654.3885457-1-shoubaineng@gmai… > > Changes in v6: > - Rework the selftest (patch 4) per review: extract a count_open_fds() > helper, fix the copy_from_user() comment, fail (not skip) when the > ioctl does not return -1, drop the bogus mprotect-race mention, and > reword the result message. > > Changes in v5: > - Add selftest (patch 4) reproducing the fd-leak scenario (Sumit Semwal) > > Changes in v4: > - Add patch 3: drm/prime: use dma_buf_fd_install() (Christian König) > - Add Acked-by: Christian König to patches 1 and 2 > > Changes in v3: > - Split into two patches (dma-heap + fastrpc separately) > - Add dma_buf_fd_install() to preserve trace_dma_buf_fd tracepoint > - Add fastrpc fix using the new helper (T.J. Mercier) > > Baineng Shou (4): > dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds > misc: fastrpc: don't publish fd before copy_to_user() succeeds > drm/prime: use dma_buf_fd_install() to preserve export tracing > selftests: dmabuf-heaps: add fd-leak-on-EFAULT regression test > > drivers/dma-buf/dma-buf.c | 20 ++++ > drivers/dma-buf/dma-heap.c | 80 ++++++------- > drivers/gpu/drm/drm_prime.c | 2 +- > drivers/misc/fastrpc.c | 16 +-- > include/linux/dma-buf.h | 1 + > .../selftests/dmabuf-heaps/dmabuf-heap.c | 113 +++++++++++++++++- > 6 files changed, 180 insertions(+), 52 deletions(-) > > -- > 2.34.1 > Best, Sumit.

2 months

Re: [PATCH v5 2/9] PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE

by Matt Evans

Hi Logan, Jason, Alex, On 05/08/2026 21:50, Logan Gunthorpe wrote: > > > On 2026-08-05 10:40, Jason Gunthorpe wrote: >> On Wed, Aug 05, 2026 at 05:28:27PM +0100, Matt Evans wrote: >>> Hi both (Logan thanks for your comments!), >>> >>> On 05/08/2026 01:39, Jason Gunthorpe wrote: >>>> On Tue, Aug 04, 2026 at 10:19:11AM -0600, Logan Gunthorpe wrote: >>>> >>>>> There's a vague convention for this already: the term 'p2pmem' is often >>>>> used for cases where the driver uses the allocator, etc. (I think I had >>>>> this intention when I wrote the code and have since forgotten about >>>>> it). >>>> >>>> I've been calling it the genalloc layer and the core layer. p2pmem >>>> would be OK to refer to the genalloc stuff. So if you want to have >>>> CONFIG_PCI_P2PDMA and CONFIG_PCI_P2PMEM that seem sOk >>>> >>>>> code into it's own file, potentially renaming some functions. Then, in >>>>> the end, we would probably have a pcim_p2pdma_supported() function and a >>>>> pcim_p2pmem_supported() function, the latter being used by existing use >>>>> cases. >>>> >>>> Not quite sure why we need this? >>> >>> ( [1] ) >>> >>>> Matt, the mlx5 stuff is the same as VFIO, it just uses the "core" >>>> layer and does not use the genalloc. So there shouldn't be an issue >>>> here, if the genalloc is off then the mlx5 stuff should still >>>> work. There shouldn't be a case where CONFIG_PCI_P2PDMA=y and mlx5 is >>>> broken? >>> >>> Oh, when CONFIG_PCI_P2PDMA=y it's all good. >>> >>> The issue is when CONFIG_PCI_P2PDMA=n, as mlx5 still seems to permit a >>> DMABUF export solely because pcim_p2pdma_provider() succeeds. (This >>> patch's CONFIG_PCI_P2PDMA_CORE enables that.) mlx5 assumes that getting >>> a provider means P2P DMA is also available. >> >> That's my point, the mlx5 should work fine with CONFIG_PCI_P2PDMA_CORE >> only or it is split wrong. >> >>> Later, DMABUF attach would fail, but it'd be good to keep the original >>> failure mode where UVERBS_METHOD_DMABUF_ALLOC fails early if no P2PDMA. >> >> Why does it fail? It should not fail :) >> >>> I was thinking something trivial like the following would let things >>> like IB fail the DMABUF_ALLOC early still, instead of making the >>> assupmtion that having a provider means having P2P DMA. E.g. OK >>> provider's available, but test for P2P DMA support too: >>> >>> bool pcim_p2pdma_supported(void) >>> { >> >> it seems illogical, if you have a provider you have p2p dma, things >> are split wrong if this is not true. >> >> The split should be only around the genalloc and related >> (sysfs,etc,etc) not anything mlx5 uses. >> >> The only think that should stop working without genalloc (ie >> CONFIG_PCI_P2PDMA=n) is nvme. > > Hmm, seems I made a few mistakes in my reply. Though I'm less certain I > understand the issue anymore. > > I did confuse in my response pcim_p2pdma_provider() and > pcim_p2pdma_supported(). The later choice I really dislike. My thinking > was we'd have two versions of pcim_p2p[dma|mem]_provider()... But I'm > not sure that's necessary. > > I thought there were callers of pcim_p2pdma_provider() in the p2pmem > code (non-core) section. But digging deeper today, it seems like > pci_p2pdma_add_resource() is the one caller, which I'd expect would be > compiled out when CONFIG_PCI_P2PDMA=n. Which seems fine. So I'm not sure > I understand the root issue anymore. Yes, this has gone round in a bit of a circle, apologies. I went back to the original change and concluded vfio-pci _doesn't_ always need a provider, so this work to refactor P2PDMA to provide a provider even when CONFIG_PCI_P2PDMA=n is unnecessary. The original original need was to break the dependency of vfio-pci on P2PDMA, since the series made vfio-pci dependent on CONFIG_VFIO_PCI_DMABUF. I'd missed that the _export_ of a DMABUF doesn't need a provider (after all, the phys_vec has the PFNs). So we can just do this: - VFIO exports DMABUF internally for mmap() - It attempts to get a provider for the export, but if CONFIG_PCI_P2PDMA=n then provider is NULL. - The DMABUF works fine for CPU access through the VMA - If someone were to fish out the DMABUF from the VMA/fds then it cannot be imported unless the provider is valid (dma_buf_map_attachment() returns -EINVAL) - Drop the P2PDMA changes entirely IOW, when CONFIG_PCI_P2PDMA=n you obviously don't get to import DMABUFs into another driver for P2P, so the provider is unused ... and when P2PDMA is supported, the VFIO BAR VMA's DMABUF has a provider, so could be imported for P2P. The struct vfio_pci_dma_buf only needs to have a valid provider if the DMABUF could possibly be imported of course. The behaviour of pcim_p2pdma_provider() is unchanged, as are any other consumers such as mlx5. This is way simpler. I will drop these first two P2PDMA refactor patches from this series. Sorry for the churn and time spent on these; though a cleanup/refactor could have merit separately it sounds like there's discussion needed on exactly what that goal should be. Matt

2 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig