Linaro-mm-sig October 2026

linaro-mm-sig@lists.linaro.org

23 participants
70 discussions

Re: [PATCH v2] udmabuf: respect the device's maximum segment size

by Kasireddy, Vivek

Hi Karl, > Subject: Re: [PATCH v2] udmabuf: respect the device's maximum > segment size > > On Tue, Sep 29, 2026 at 07:48:35AM +0100, Karl Mehltretter wrote: > > get_sg_table() merges physically contiguous pages without accounting > > for the mapping device's maximum segment size. This affects both > > importer mappings and the udmabuf misc device mapping used for > CPU > > access. > > > > With DMA_API_DEBUG enabled, DMA_BUF_IOCTL_SYNC on a 64 MiB > udmabuf > > reports: > > > > DMA-API: misc udmabuf: mapping sg segment longer than device > claims to > > support [len=65884160] [max=65536] > > > > Use sg_alloc_table_from_pages_segment() with the mapping device's > > maximum segment size. Return -EINVAL if the limit is smaller than > > PAGE_SIZE because the page-based allocator cannot honor it. > > > > Before commit 5bf888673e0d ("udmabuf: Do not create malformed > > scatterlists"), each entry covered one page. > > > > Fixes: 5bf888673e0d ("udmabuf: Do not create malformed > scatterlists") > > Reviewed-by: Jason Gunthorpe <jgg(a)nvidia.com> > > Assisted-by: LLM > > Signed-off-by: Karl Mehltretter <kmehltretter(a)gmail.com> > > Friendly ping on v2. It has Reviewed-by tags from Jason and Christian. Will push this patch to drm-misc-next soon (in a day or two). Thanks, Vivek > > Thanks, > Karl

1 week, 3 days

Re: [PATCH 13/13] arm64: dts: qcom: hawi: Add DCP support

by Krzysztof Kozlowski

On Thu, Oct 15, 2026 at 01:08:33PM +0530, Jayant Shekhar wrote: > diff --git a/arch/arm64/boot/dts/qcom/hawi.dtsi b/arch/arm64/boot/dts/qcom/hawi.dtsi > index 0926d880cb0c..58fcf42cbaba 100644 > --- a/arch/arm64/boot/dts/qcom/hawi.dtsi > +++ b/arch/arm64/boot/dts/qcom/hawi.dtsi > @@ -8235,4 +8235,63 @@ timer { > <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, > <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; > }; > + > + dcp: virtio@9be8000 { > + compatible = "qcom,dcp-virtio", "virtio,mmio"; More slop. At least you could ask your agent to TEST it. See internal guidelines how to do it. Best regards, Krzysztof

1 week, 4 days

Re: [PATCH 01/13] dt-bindings: display: msm: Add Qualcomm DCP bindings

by Krzysztof Kozlowski

On Thu, Oct 15, 2026 at 01:08:21PM +0530, Jayant Shekhar wrote: > DCP platforms place the display pipeline under firmware control, so Linux > cannot discover display resources through direct register access. The DRM > driver therefore needs device-tree descriptions of the firmware transport, > display topology, IOMMU contexts, and panel connections. Due to dependencies this cannot be tested, so limited review. A nit, subject: drop second/last, redundant "bindings". The "dt-bindings" prefix is already stating that these are bindings. See also: https://elixir.bootlin.com/linux/v7.1-rc7/source/Documentation/devicetree/b… > > Add bindings for the Qualcomm DCP VirtIO display function, including the > INTF graph and DSI host outputs. Document the framebuffer IOMMU context, > IPCC power-notify mailbox and interrupts, firmware display topology, and > firmware-visible IOVA window supplied by the parent VirtIO-MMIO transport. > > Signed-off-by: Jayant Shekhar <jayant.shekhar(a)oss.qualcomm.com> > Assisted-by: LLM > --- > .../bindings/display/msm/qcom,dcp-dsi.yaml | 75 +++++++++++++ > .../bindings/display/msm/qcom,dcp-virtio.yaml | 113 +++++++++++++++++++ > .../devicetree/bindings/display/msm/qcom,dcp.yaml | 119 +++++++++++++++++++++ > 3 files changed, 307 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/msm/qcom,dcp-dsi.yaml b/Documentation/devicetree/bindings/display/msm/qcom,dcp-dsi.yaml > new file mode 100644 > index 000000000000..f7178c66c09e > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/msm/qcom,dcp-dsi.yaml > @@ -0,0 +1,75 @@ > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/msm/qcom,dcp-dsi.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Qualcomm DCP DSI host > + > +maintainers: > + - Jayant Shekhar <jayant.shekhar(a)oss.qualcomm.com> > + > +description: | > + A MIPI DSI host exposed by the Qualcomm DCP VirtIO device (see > + qcom,dcp.yaml). DCP is a firmware protocol shared across multiple > + Qualcomm SoCs, not specific to any one of them; Hawi is its first > + platform. The DSI host and its connection to a panel are described > + using the standard DSI controller and OF graph properties. > + > +allOf: > + - $ref: /schemas/display/dsi-controller.yaml# > + > +properties: > + reg: > + maxItems: 1 > + description: Index of this DSI host among its siblings. > + > + status: true I see slop, I finished here. Mind this maintainers summit words - if you use AI, you must use good one, not the shloppy slop. Best regards, Krzysztof

1 week, 4 days

[PATCH v8 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. This is achieved by allowing the processes to mmap() the DMABUFs; their access to the device is isolated to the exported ranges. The primary userspace driver process can forcibly revoke access to previously-shared buffers upon cleanup (without requiring cooperation from the subordinate processes). This is an improvement on sharing the VFIO device fd to subordinate processes, which would allow unfettered access. See the RFCs for background. The existing VFIO PCI BAR mmap() becomes backed by a DMABUF too, keeping common vm_ops and fault handler for VMAs from 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. Below are per-patch notes & background info, and at the bottom are several related questions that reviewers may like to consider (worth at least skipping to #1, a possible bug). Notes on patches ================ 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. It's also worth noting that one reason for nvgrace-gpu's special BAR handling is to map RESMEM with a WC memory type. This is unchanged for existing mmap() but WC is not currently supported for mapping DMABUFs exported for that BAR; all DMABUF VMAs currently have the same memory type and control of UC/WC for a mapping is future work. vfio/pci: Remove DMABUF export dependency on vdev->memory_lock In v5 of this series we discover that doing an export from the VFIO mmap() path (fundamental!) adds a dependency between mmap_lock and vdev->memory_lock(W) because export was using memory_lock(W) to protect the vdev->dmabufs list and state within, and a deadlock scenario leapt out to bite: https://lore.kernel.org/kvm/9a615f22-c0d4-46ae-9654-db11e94e5fec@ozlabs.org/ The suggestion was to add a dedicated mutex/rwsem specifically for the DMABUFs/list, which is cleaner than overloading memory_lock(W). But whilst export could now downgrade to holding memory_lock(R) to test __vfio_pci_memory_enabled(), a very similar deadlock can still arise due to a memory_lock(W) elsewhere depending on a prior memory_lock(R) to be released, and attempting to take memory_lock(R) will queue behind the (W) for fairness (effectively an R->R dependency). I'd overlooked that rwsem cannot guarantee multiple readers. To be able to export while holding mmap_lock, export cannot hold memory_lock at all. Instead of testing __vfio_pci_memory_enabled() (which tracks PCI_COMMAND.MSE and PM state), this patch tracks device-global DMABUF revocation state in a new vdev->bars_revoked flag updated by vfio_pci_dma_buf_move(). If an mmap() is somehow performed during a period when DMABUFs are all revoked, then the DMABUF is created revoked. Move() already bookends reset, PM transitions etc., so subsequent revocation state changes work as-is. This flag is also protected by the dmabuf_lock and thus memory_lock is not required to export. vfio/pci: Un-revoke DMABUFs in LOW_POWER_ENTRY_WITH_WAKEUP resume On LOW_POWER entry, DMABUFs have a move(revoke=true), but the runtime resume path didn't un-revoke. This adds a corresponding move(revoke=false), which will later turn into vfio_pci_unrevoke_bars(). NOTE: the unrevoke is reordered _before_ the eventfd_signal() in vfio_pci_core_runtime_resume() to remove a window in which a waking waiter could have observed the DMABUF state as still revoked (or pm_runtime_engaged = true). (The UAPI docs state the event means the resume's complete, so observing otherwise seemed unintended.) Also, when DMABUFs are later mmap()ed, a waiter waking and taking a fault could have seen the unrevoked state and SIGBUS just before taking the memory_lock. (If the handler gets to acquire the lock, though, the resume sequence is complete, and the handler observes pm_runtime_engaged = false.) This fix is in this series because the issue will impact CPU access to the VMA as well (once they use DMABUFs), and so it's a strict dependency of later commits. dma-buf: Provide dma_buf_set_name() Makes dma_buf_set_name() available for use (by helper patch), taking a kernel-allocated string. The pre-existing local helper becomes a wrapper copying a __user string for the set-name ioctl. vfio/pci: Add a helper to look up PFNs for DMABUFs Adds a DMABUF VMA fault handler helper to determine arbitrary-sized PFNs from ranges in DMABUF. vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA 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. 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 mmap()ed. The name is installed with the new dma_buf_set_name() above. 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. NOTE: As local LLM reviews did, Sashiko might falsely worry about the DMABUF fd being obtained through /proc/pid/map_files and remapped, but the file is an anon inode and doesn't support the open op (-ENXIO) so AFAICT this is currently impossible. NOTE: A side-effect of this is that is_mergeable_vma() will be false between adjacent mappings of VFIO BARs; merging would require rebuilding a larger DMABUF representing the union, not just plugging the VMAs together. The DMABUF backing the BAR is an implicit/internal export, even when the CONFIG_VFIO_PCI_DMABUF feature is not included because CONFIG_PCI_P2PDMA is not available. Without P2PDMA, it's acceptable for the DMABUF to not have a P2PDMA provider. In this configuration, the VFIO DMABUF .attach prohibits any import, which avoids getting as far as a WARN in dma_buf_map_attachment(), which would fail without P2PDMA anyway. 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 the locks in vdev are touched; this holds the device registration so that even if the buffer has been cleaned up, vdev hasn't been freed and so the locks can be safely taken. vfio/pci: Revoke a DMABUF on request from userspace 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 used by ..._move() and this new feature. Testing ======= (The [RFC ONLY] userspace test program, which drives a QEMU bochs-display function, can be found in the GitHub branch below. It at least illustrates how the export, map, revoke, and close semantics interoperate. WIP on a follow-up with a proper vfio-selftests style test based on this -- this won't be part of this series.) 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. Thanks to Alex Mastro for building a (WIP) testcase for the prior mmap_lock->memory_lock issue. END === This is based on v7.3-rc6 These commits are on GitHub for easier browsing, along with "[RFC ONLY] selftests: vfio: Add standalone vfio_dmabuf_mmap_test": https://github.com/evansm7/linux/compare/v7.3-rc6...dev/mev/vfio-dmabuf-mma… Also please see... https://lore.kernel.org/all/f8efaabd-c06e-4f04-8cfa-489c148e37ba@ozlabs.org/ ("[PATCH] dma-buf: Annul dmabuf->file on file release") ...which fixes a stale file pointer issue that could affect VFIO's DMABUF export. Although the issue exists prior to this series, the addition of another dmabuf->file dereference adds additional unpleasant failure modes (for example, unmap_mapping_range() the wrong file, or good old random data dereference, etc.) Thanks for reading, Matt ================================================================================ Changelog: v8: - Rebased, on v7.3-rc6 - "dma-buf: Provide dma_buf_set_name()": Comment and "DOC: locking convention" updates. dma_buf_set_name() is is listed in the "do not hold resv" category v7: https://lore.kernel.org/all/20260924152159.49702-1-matt@ozlabs.org/ v6: https://lore.kernel.org/all/20260911214200.33793-1-matt@ozlabs.org/ v5: https://lore.kernel.org/all/20260715174737.15287-1-matt@ozlabs.org/ 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): vfio/pci: Remove DMABUF export dependency on vdev->memory_lock vfio/pci: Un-revoke DMABUFs in LOW_POWER_ENTRY_WITH_WAKEUP resume dma-buf: Provide dma_buf_set_name() 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: Clean up BAR zap and revocation vfio/pci: Support mmap() of a VFIO DMABUF vfio/pci: Revoke a DMABUF on request from userspace drivers/dma-buf/dma-buf.c | 84 ++- drivers/vfio/pci/Kconfig | 4 +- drivers/vfio/pci/Makefile | 3 +- .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 14 +- drivers/vfio/pci/vfio_pci_config.c | 30 +- drivers/vfio/pci/vfio_pci_core.c | 222 +++++-- drivers/vfio/pci/vfio_pci_dmabuf.c | 609 +++++++++++++++--- drivers/vfio/pci/vfio_pci_priv.h | 54 +- include/linux/dma-buf.h | 16 +- include/linux/vfio_pci_core.h | 3 + include/uapi/linux/vfio.h | 24 + 11 files changed, 870 insertions(+), 193 deletions(-) -- 2.47.3

1 week, 5 days

Re: [PATCH v11 08/13] nvme-pci: add SGL support for the dmabuf path

by Christoph Hellwig

Looks good: Reviewed-by: Christoph Hellwig <hch(a)lst.de>

1 week, 5 days

Re: [PATCH v11 07/13] nvme-pci: implement dma-buf backed requests

by Christoph Hellwig

Looks good: Reviewed-by: Christoph Hellwig <hch(a)lst.de>

1 week, 5 days

Re: [PATCH v11 04/13] block: introduce dma map backed bio type

by Christoph Hellwig

On Wed, Oct 14, 2026 at 12:02:02PM +0100, Pavel Begunkov wrote: > Premapped buffers don't require a generic bio_vec since these have > already been dma mapped. Repurpose the bi_io_vec space to store dmabuf > maps as they are mutually exclusive. > > The bio splitting differs from the normal path because it's already > pre-mapped and for the block layer it's just an offset into the dma-buf. > The actual segmentation is only available to the importer driver and not > the block layer, however, it doesn't contain alignment gaps and we don't > have to check it. For the same reason we can't precisely split by the > number of segments, but we use ->min_seg_shift stored in the map to > calculate the minimum number of bytes a request consisting of > lim->max_segments full segments can cover and split by that. It's > stricter and can add extra splitting. E.g. for a {4K, 4G} segmentation, > the min segment size is 4K, and we'll split it into bios of > (4K * lim->max_segments) bytes each, but it should be good enough for > now to cover the most popular use cases. > > Suggested-by: Keith Busch <kbusch(a)kernel.org> > Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com> > --- > block/bio.c | 15 +++++++++-- > block/blk-merge.c | 52 +++++++++++++++++++++++++++++++++++++++ > block/blk-mq.c | 6 +++++ > block/fops.c | 2 +- > include/linux/bio.h | 9 ++++--- > include/linux/blk-mq.h | 7 ++++++ > include/linux/blk_types.h | 14 ++++++++++- > include/linux/bvec.h | 3 ++- > 8 files changed, 99 insertions(+), 9 deletions(-) > > diff --git a/block/bio.c b/block/bio.c > index b48091c7663f..1e0d9714c541 100644 > --- a/block/bio.c > +++ b/block/bio.c > @@ -881,7 +881,11 @@ static int __bio_clone(struct bio *bio, struct bio *bio_src, gfp_t gfp) > bio->bi_write_stream = bio_src->bi_write_stream; > bio->bi_bvec_gap_bit = bio_src->bi_bvec_gap_bit; > bio->bi_iter = bio_src->bi_iter; > - bio->bi_io_vec = bio_src->bi_io_vec; > + > + if (op_is_dmabuf(bio->bi_opf)) > + bio->bi_dmabuf_map = bio_src->bi_dmabuf_map; > + else > + bio->bi_io_vec = bio_src->bi_io_vec; > > if (bio->bi_bdev) { > if (bio->bi_bdev == bio_src->bi_bdev && > @@ -1204,16 +1208,23 @@ EXPORT_SYMBOL_GPL(__bio_release_pages); > > bool bio_iov_iter_set(struct bio *bio, const struct iov_iter *iter) > { > - if (!iov_iter_is_bvec(iter)) > + if (!iov_iter_is_bvec(iter) && !iov_iter_is_dmabuf_map(iter)) > return false; > > WARN_ON_ONCE(bio->bi_max_vecs); > > + static_assert(offsetof(struct bio, bi_io_vec) == > + offsetof(struct bio, bi_dmabuf_map)); > + static_assert(offsetof(struct iov_iter, bvec) == > + offsetof(struct iov_iter, dmabuf_map)); > + > bio->bi_io_vec = (struct bio_vec *)iter->bvec; > bio->bi_iter.bi_idx = 0; > bio->bi_iter.bi_offset = iter->iov_offset; > bio->bi_iter.bi_size = iov_iter_count(iter); > bio_set_flag(bio, BIO_CLONED); > + if (iov_iter_is_dmabuf_map(iter)) > + bio->bi_opf |= REQ_NOMERGE | REQ_DMABUF; > return true; > } > > diff --git a/block/blk-merge.c b/block/blk-merge.c > index 258a726071d1..501ddc01c449 100644 > --- a/block/blk-merge.c > +++ b/block/blk-merge.c > @@ -9,6 +9,7 @@ > #include <linux/blk-integrity.h> > #include <linux/part_stat.h> > #include <linux/blk-cgroup.h> > +#include <linux/dma-buf-io.h> > > #include <trace/events/block.h> > > @@ -319,6 +320,41 @@ static inline unsigned int bvec_seg_gap(struct bio_vec *bvprv, > return bv->bv_offset | (bvprv->bv_offset + bvprv->bv_len); > } > > +static inline int bio_split_io_at_dmabuf(struct bio *bio, > + const struct queue_limits *lim, unsigned *segs, > + unsigned max_bytes, unsigned len_align_mask, > + unsigned start_align_mask) > +{ > + unsigned bytes = min(bio->bi_iter.bi_size, max_bytes); > + unsigned seg_shift = bio->bi_dmabuf_map->min_seg_shift; > + unsigned offset = bio->bi_iter.bi_offset & ((1U << seg_shift) - 1); > + u64 max_segs_bytes; > + > + /* > + * dma-buf maps don't expose the underlying segmentation, but they're > + * guaranteed to not have alignment gaps, we only need to check the > + * start and length alignment. > + */ > + if ((bio->bi_iter.bi_offset & start_align_mask) || > + (bio->bi_iter.bi_size & len_align_mask)) > + return -EINVAL; > + > + /* Presented as a single contiguous range into the dma-buf */ > + *segs = 1; > + > + /* > + * Limit by the number of segments by using the minimal segment size. > + * Any I/O consisting of N full segments should be able to cover at > + * least N multiplied by the segment size. It's stricter than walking > + * the segments and might cause extra splitting. > + */ > + max_segs_bytes = (u64)lim->max_segments << seg_shift; > + bytes = min_t(u64, bytes, max_segs_bytes - offset); > + if (bytes != bio->bi_iter.bi_size) > + return bytes; > + return 0; > +} > + > /** > * bio_split_io_at - check if and where to split a bio > * @bio: [in] bio to be split > @@ -346,6 +382,19 @@ int bio_split_io_at(struct bio *bio, const struct queue_limits *lim, > len_align_mask |= (bc->bc_key->crypto_cfg.data_unit_size - 1); > } > > + if (op_is_dmabuf(bio->bi_opf)) { > + int ret; > + > + ret = bio_split_io_at_dmabuf(bio, lim, &nsegs, max_bytes, > + len_align_mask, start_align_mask); > + if (ret < 0) > + return ret; > + if (!ret) > + goto out; > + bytes = ret; > + goto split; > + } > + > bio_for_each_bvec(bv, bio, iter) { > if (bv.bv_offset & start_align_mask || > bv.bv_len & len_align_mask) > @@ -376,6 +425,7 @@ int bio_split_io_at(struct bio *bio, const struct queue_limits *lim, > bvprvp = &bvprv; > } > > +out: > *segs = nsegs; > bio->bi_bvec_gap_bit = ffs(gaps); > return 0; > @@ -493,6 +543,8 @@ unsigned int blk_recalc_rq_segments(struct request *rq) > > if (!rq->bio) > return 0; > + if (op_is_dmabuf(rq->bio->bi_opf)) > + return 1; > > switch (bio_op(rq->bio)) { > case REQ_OP_DISCARD: > diff --git a/block/blk-mq.c b/block/blk-mq.c > index e929f94b25c7..1b7f8cbbda8b 100644 > --- a/block/blk-mq.c > +++ b/block/blk-mq.c > @@ -3150,6 +3150,12 @@ void blk_mq_submit_bio(struct bio *bio) > goto queue_exit; > } > > + if (unlikely(op_is_dmabuf(bio->bi_opf) && > + bdev_has_integrity_csum(bio->bi_bdev))) { > + bio_endio_status(bio, BLK_STS_NOTSUPP); Wrong indentation, conditions are never indented the same level as the following code block, even with the weirdest preferences. /me note the patch from Anuj on the list actually got this right.. Otherwise looks good: Reviewed-by: Christoph Hellwig <hch(a)lst.de>

1 week, 5 days

Re: [PATCH v2] dma-buf/test: add KUnit case for dma_fence_dedup_array() empty input

by Christian König

On 10/14/26 04:49, Baineng Shou wrote: > Add a KUnit case verifying that dma_fence_dedup_array() returns 0, > not 1, when called with num_fences == 0. This locks down the > contract documented in the kernel-doc and prevents a regression > of commit 77a9298741f8 ("dma-fence: Make dma_fence_dedup_array() > robust against 0-count input"). > > Suggested-by: Christian König <christian.koenig(a)amd.com> > Reviewed-by: Christian König <christian.koenig(a)amd.com> > Signed-off-by: Baineng Shou <shoubaineng(a)gmail.com> Thanks for the reminder, I had to wait for the -fixes backmerge to push this. I've just pushed the patch to drm-misc-next. Regards, Christian. > --- > > Changes in v2: > - Add Reviewed-by from Christian. > - Rebase onto v7.3-rc7. > > drivers/dma-buf/st-dma-fence-unwrap.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/dma-buf/st-dma-fence-unwrap.c b/drivers/dma-buf/st-dma-fence-unwrap.c > index 4d9d313b460c..c5353b36f0e4 100644 > --- a/drivers/dma-buf/st-dma-fence-unwrap.c > +++ b/drivers/dma-buf/st-dma-fence-unwrap.c > @@ -370,6 +370,15 @@ static void test_unwrap_merge_seqno(struct kunit *test) > dma_fence_put(f1); > } > > +static void test_dedup_empty(struct kunit *test) > +{ > + struct dma_fence *fence[1] = { NULL }; > + int ret; > + > + ret = dma_fence_dedup_array(fence, 0); > + KUNIT_EXPECT_EQ(test, ret, 0); > +} > + > static void test_unwrap_merge_order(struct kunit *test) > { > struct dma_fence *fence, *f1, *f2, *a1, *a2, *c1, *c2; > @@ -595,6 +604,7 @@ static struct kunit_case dma_fence_unwrap_cases[] = { > KUNIT_CASE(test_unwrap_merge_order), > KUNIT_CASE(test_unwrap_merge_complex), > KUNIT_CASE(test_unwrap_merge_complex_seqno), > + KUNIT_CASE(test_dedup_empty), > {} > }; >

1 week, 5 days

Re: [PATCH v11 01/13] dma-buf: introduce initial file I/O infrastructure

by Christian König

On 10/14/26 13:01, Pavel Begunkov wrote: > The goal is to be able to natively use dma-buf in the read-write / IO > path. This patch adds basic building blocks serving as a glue and API > between drivers and upper layer subsystems providing the uAPI. Later > patches implement it for NVMe raw block devices and expose it to the > user space via io_uring. > > There are two main objects. struct dma_buf_io_ctx and struct > dma_buf_io_map. The ctx is used during initial registration and serves > as an interface between the upper layer user like io_uring and to the > importer subsystem / driver. The map represents the actual dma map > established for the target device[s] with dma_buf_map_attachment() and > stored in a device specific format. The context is created via a new > file operation ->init_dma_buf_io_ctx. > > The ctx-map separation exists to facilitate map invalidation (see > dma_buf_io_invalidate_mappings()). A ctx can create > multiple maps during its lifetime, but there can only be no more than > one (active) map attached to it. Invalidation drops the active map > if present, and any new I/O request will try to create a new one. > > The primary task of dma_buf_io_map is to count requests using it > and wait for their completion when we want to destroy the DMA map. > > [un]mapping and any work with dma addresses is delegated to the > importer driver via an ops table stored in the ctx, see struct > dma_buf_io_ops. Only the target driver / subsystem knows about devices > it wants to use the dma-buf with, especially in case of multi-device > filesystems or stacking in the future. > > Acked-by: Matthew Brost <matthew.brost(a)intel.com> > Tested-by: Matthew Brost <matthew.brost(a)intel.com> > Acked-by: Christian König <christian.koenig(a)amd.com> > Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com> > --- > drivers/dma-buf/Makefile | 2 +- > drivers/dma-buf/dma-buf-io.c | 229 +++++++++++++++++++++++++++++++++++ > include/linux/dma-buf-io.h | 125 +++++++++++++++++++ > include/linux/fs.h | 2 + > 4 files changed, 357 insertions(+), 1 deletion(-) > create mode 100644 drivers/dma-buf/dma-buf-io.c > create mode 100644 include/linux/dma-buf-io.h > > diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile > index b25d7550bacf..523731b0f83e 100644 > --- a/drivers/dma-buf/Makefile > +++ b/drivers/dma-buf/Makefile > @@ -1,6 +1,6 @@ > # SPDX-License-Identifier: GPL-2.0-only > obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \ > - dma-fence-unwrap.o dma-resv.o dma-buf-mapping.o > + dma-fence-unwrap.o dma-resv.o dma-buf-mapping.o dma-buf-io.o > obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o > obj-$(CONFIG_DMABUF_HEAPS) += heaps/ > obj-$(CONFIG_SYNC_FILE) += sync_file.o > diff --git a/drivers/dma-buf/dma-buf-io.c b/drivers/dma-buf/dma-buf-io.c > new file mode 100644 > index 000000000000..21296bd3dde1 > --- /dev/null > +++ b/drivers/dma-buf/dma-buf-io.c > @@ -0,0 +1,229 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Common infrastructure for supporing dma-buf in the I/O path. > + * > + * Copyright (C) 2026 Pavel Begunkov <asml.silence(a)gmail.com> > + */ > +#include <linux/dma-buf-io.h> > +#include <linux/dma-resv.h> > + > +static void dma_buf_io_map_release(struct dma_buf_io_map *map) > +{ > + struct dma_buf_io_ctx *ctx = map->ctx; > + > + dma_resv_assert_held(ctx->dmabuf->resv); > + > + percpu_ref_exit(&map->refs); > + ctx->dev_ops->unmap(ctx, map); > +} > + > +static void dma_buf_io_map_refs_cb(struct percpu_ref *ref) > +{ > + struct dma_buf_io_map *map = container_of(ref, struct dma_buf_io_map, refs); > + > + complete(&map->drained); > +} > + > +static void dma_buf_io_kill_map(struct dma_buf_io_ctx *ctx) > +{ > + struct dma_buf_io_map *map; > + > + dma_resv_assert_held(ctx->dmabuf->resv); > + > + map = rcu_dereference_protected(ctx->map, > + dma_resv_held(ctx->dmabuf->resv)); > + if (!map) > + return; > + > + rcu_assign_pointer(ctx->map, NULL); > + percpu_ref_kill(&map->refs); > + /* make sure the map is not visible via ctx->map */ > + synchronize_rcu_expedited(); > + wait_for_completion(&map->drained); > + dma_buf_io_map_release(map); > +} > + > +int dma_buf_io_init_map(struct dma_buf_io_ctx *ctx, struct dma_buf_io_map *map, > + struct sg_table *sgt) You somehow forgotten the kerneldoc I asked for here. Apart from that still looks good, but I had only time to skim over it. Regards, Christian. > +{ > + unsigned seg_shift = ~0U; > + struct scatterlist *sg; > + unsigned long tmp; > + int ret; > + > + for_each_sgtable_dma_sg(sgt, sg, tmp) > + seg_shift = min(seg_shift, __ffs(sg_dma_len(sg))); > + > + ret = percpu_ref_init(&map->refs, dma_buf_io_map_refs_cb, 0, GFP_KERNEL); > + if (ret) > + return ret; > + init_completion(&map->drained); > + map->min_seg_shift = seg_shift; > + map->ctx = ctx; > + return 0; > +} > +EXPORT_SYMBOL_NS_GPL(dma_buf_io_init_map, "DMA_BUF"); > + > +static struct dma_buf_io_map *__dma_buf_io_create_map(struct dma_buf_io_ctx *ctx) > +{ > + struct dma_buf *dmabuf = ctx->dmabuf; > + struct dma_buf_io_map *map; > + long ret; > + > + dma_resv_assert_held(dmabuf->resv); > + > + if (ctx->is_dead) > + return ERR_PTR(-ENOENT); > + > + map = __dma_buf_io_get_map(ctx); > + if (map) > + return map; > + > + map = ctx->dev_ops->map(ctx); > + if (IS_ERR(map)) > + return map; > + > + if (WARN_ON_ONCE(!map->min_seg_shift)) > + return ERR_PTR(-EFAULT); > + > + ret = dma_resv_wait_timeout(dmabuf->resv, DMA_RESV_USAGE_KERNEL, > + true, MAX_SCHEDULE_TIMEOUT); > + if (ret <= 0) { > + if (!ret) > + ret = -EAGAIN; > + dma_buf_io_map_release(map); > + return ERR_PTR(ret); > + } > + > + /* get a reference for the caller */ > + percpu_ref_get(&map->refs); > + rcu_assign_pointer(ctx->map, map); > + return map; > +} > + > +/** > + * dma_buf_io_create_map - Create a new or reference an existing map. > + * @ctx: [in] dma-buf I/O context > + * > + * A slow path part of dma_buf_io_get_map() and shouldn't be used directly. > + * Behaves in the same way but allowed to block. > + * > + * Returns a map on success, or ERR_PTR encoded errno otherwise. > + */ > +struct dma_buf_io_map *dma_buf_io_create_map(struct dma_buf_io_ctx *ctx) > +{ > + struct dma_buf_io_map *map; > + int ret; > + > + ret = dma_resv_lock_interruptible(ctx->dmabuf->resv, NULL); > + if (ret) > + return ERR_PTR(ret); > + > + map = __dma_buf_io_create_map(ctx); > + dma_resv_unlock(ctx->dmabuf->resv); > + return map; > +} > + > +static void dma_buf_io_ctx_shutdown(struct dma_buf_io_ctx *ctx) > +{ > + dma_resv_lock(ctx->dmabuf->resv, NULL); > + ctx->is_dead = true; > + dma_buf_io_kill_map(ctx); > + dma_resv_unlock(ctx->dmabuf->resv); > +} > + > +/* > + * dma_buf_io_ctx_create - create a new dma-buf I/O context for the given file. > + * @file: [in] file for which the context is created > + * @dmabuf: [in] buffer to create a context from > + * @dir: [in] direction of DMA transfers > + * @out_ctx [out] resulting ctx > + * > + * Create a new I/O context from the given DMA buffer for the given file. > + * It only works with files implementing ->init_dma_buf_io_ctx and fails > + * with -EOPNOTSUPP otherwise. Once created, the user can create a map > + * and use it to issue I/O like read / write requests to @file. > + */ > +int dma_buf_io_ctx_create(struct file *file, > + struct dma_buf *dmabuf, > + enum dma_data_direction dir, > + struct dma_buf_io_ctx **out_ctx) > +{ > + struct dma_buf_io_ctx *ctx; > + int ret; > + > + if (!file->f_op->init_dma_buf_io_ctx) > + return -EOPNOTSUPP; > + > + ctx = kzalloc_obj(*ctx); > + if (!ctx) > + return -ENOMEM; > + ctx->dir = dir; > + ctx->dmabuf = dmabuf; > + get_dma_buf(dmabuf); > + > + ret = file->f_op->init_dma_buf_io_ctx(file, ctx); > + if (ret) { > + kfree(ctx); > + dma_buf_put(dmabuf); > + return ret; > + } > + > + if (WARN_ON_ONCE(!ctx->dev_ops || > + !ctx->dev_ops->map || > + !ctx->dev_ops->unmap || > + !ctx->dev_ops->release)) > + return -EINVAL; > + > + *out_ctx = ctx; > + return 0; > +} > + > +/** > + * dma_buf_io_ctx_release - destroy the I/O context > + * @ctx: [in] dma-buf I/O context > + * > + * Destroy the context. It makes sure all maps are waited on and destroyed, > + * and can block for I/O to complete. It detaches from the importer and > + * destroys all its resources via the ->release callback, and frees the > + * context. > + */ > +void dma_buf_io_ctx_release(struct dma_buf_io_ctx *ctx) > +{ > + dma_buf_io_ctx_shutdown(ctx); > + > + if (WARN_ON_ONCE(rcu_dereference_protected(ctx->map, true))) > + return; > + > + ctx->dev_ops->release(ctx); > + dma_buf_put(ctx->dmabuf); > + kfree(ctx); > +} > + > +/** > + * dma_buf_io_invalidate_mappings - invalidate the current map > + * @ctx: [in] dma-buf I/O context > + * > + * Importer's helper for invalidating the current map. Waits for all I/O > + * using the map to complete and destroyes the map. Called with the > + * dma-buf reservation lock held. > + */ > +void dma_buf_io_invalidate_mappings(struct dma_buf_io_ctx *ctx) > +{ > + dma_buf_io_kill_map(ctx); > +} > +EXPORT_SYMBOL_NS_GPL(dma_buf_io_invalidate_mappings, "DMA_BUF"); > + > +/** > + * dma_buf_io_detach - detach the @ctx from the importer. > + * @ctx: [in] dma-buf I/O context > + * > + * Importer's helper for removing the I/O ctx. It kills all maps and > + * prevents creation of new ones. Upon return it's safe for the importer > + * to release all its resources such as dma-buf attachments. > + */ > +void dma_buf_io_detach(struct dma_buf_io_ctx *ctx) > +{ > + dma_buf_io_ctx_shutdown(ctx); > +} > +EXPORT_SYMBOL_NS_GPL(dma_buf_io_detach, "DMA_BUF"); > diff --git a/include/linux/dma-buf-io.h b/include/linux/dma-buf-io.h > new file mode 100644 > index 000000000000..b9bbeca1744f > --- /dev/null > +++ b/include/linux/dma-buf-io.h > @@ -0,0 +1,125 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef __DMA_BUF_IO_H__ > +#define __DMA_BUF_IO_H__ > + > +#include <linux/dma-buf.h> > + > +struct dma_buf_io_ctx; > +struct dma_buf_io_map; > + > +struct dma_buf_io_ops { > + /* > + * Create a new map for the given ctx. Called with the reservation > + * lock held. > + */ > + struct dma_buf_io_map *(*map)(struct dma_buf_io_ctx *ctx); > + > + /* > + * Clean up device specific parts of the @map. Called with the > + * reservation lock held. > + */ > + void (*unmap)(struct dma_buf_io_ctx *ctx, struct dma_buf_io_map *map); > + > + /* > + * The user tries to destroy the ctx. Release all device specific > + * parts of the token. > + */ > + void (*release)(struct dma_buf_io_ctx *); > +}; > + > +struct dma_buf_io_map { > + /* > + * Counts attached requests and other users. Device specific unmapping > + * is deferred until all refs are dropped. > + */ > + struct percpu_ref refs; > + /* > + * Shift for the minimum segment size of the mapping. > + */ > + unsigned min_seg_shift; > + > + struct dma_buf_io_ctx *ctx; > + struct completion drained; > +}; > + > +struct dma_buf_io_ctx { > + struct dma_buf_io_map __rcu *map; > + struct dma_buf *dmabuf; > + enum dma_data_direction dir; > + bool is_dead; > + > + void *dev_priv; > + const struct dma_buf_io_ops *dev_ops; > +}; > + > +int dma_buf_io_ctx_create(struct file *file, > + struct dma_buf *dmabuf, > + enum dma_data_direction dir, > + struct dma_buf_io_ctx **ctx); > +void dma_buf_io_ctx_release(struct dma_buf_io_ctx *ctx); > + > +struct dma_buf_io_map *dma_buf_io_create_map(struct dma_buf_io_ctx *ctx); > + > +static inline struct dma_buf_io_map * > +__dma_buf_io_get_map(struct dma_buf_io_ctx *ctx) > +{ > + struct dma_buf_io_map *map; > + > + guard(rcu)(); > + > + map = rcu_dereference(ctx->map); > + if (unlikely(!map || !percpu_ref_tryget_live_rcu(&map->refs))) > + return NULL; > + > + return map; > +} > + > +/** > + * dma_buf_io_get_map - Create a new or reference an existing map. > + * @ctx: [in] dma-buf I/O context > + * @nowait: [in] specifies whether it's allowed to block > + * > + * Create a new or acquire an existing map. When succeeds, it returns > + * a referenced map, which should eventually be put down with > + * dma_buf_io_map_drop(). If @nowait is set and the function would block, > + * it return -EAGAIN, and the caller is expected to retry from a context > + * where blocking is allowed. > + * > + * Returns a map on success, or ERR_PTR encoded errno otherwise. > + */ > +static inline struct dma_buf_io_map * > +dma_buf_io_get_map(struct dma_buf_io_ctx *ctx, bool nowait) > +{ > + struct dma_buf_io_map *map; > + > + map = __dma_buf_io_get_map(ctx); > + if (likely(map)) > + return map; > + > + if (nowait) > + return ERR_PTR(-EAGAIN); > + return dma_buf_io_create_map(ctx); > +} > + > +/** > + * dma_buf_io_map_drop - Drop the map. > + * @map: [in] dma-buf I/O map > + * > + * Put down a reference for the @map acquired via dma_buf_io_get_map(). > + * Should be called as soon as I/O is completed. > + */ > +static inline void dma_buf_io_map_drop(struct dma_buf_io_map *map) > +{ > + percpu_ref_put(&map->refs); > +} > + > +/* > + * Device API > + */ > + > +void dma_buf_io_invalidate_mappings(struct dma_buf_io_ctx *ctx); > +int dma_buf_io_init_map(struct dma_buf_io_ctx *ctx, struct dma_buf_io_map *map, > + struct sg_table *sgt); > +void dma_buf_io_detach(struct dma_buf_io_ctx *ctx); > + > +#endif > diff --git a/include/linux/fs.h b/include/linux/fs.h > index f9d1e05e8ae6..05c1ff495732 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -1914,6 +1914,7 @@ struct dir_context { > #define COPY_FILE_SPLICE (1 << 0) > > struct io_uring_cmd; > +struct dma_buf_io_ctx; > struct offset_ctx; > > struct file_operations { > @@ -1960,6 +1961,7 @@ struct file_operations { > int (*uring_cmd_iopoll)(struct io_uring_cmd *, struct io_comp_batch *, > unsigned int poll_flags); > int (*mmap_prepare)(struct vm_area_desc *); > + int (*init_dma_buf_io_ctx)(struct file *, struct dma_buf_io_ctx *); > } __randomize_layout; > > /* Supports async buffered reads */

1 week, 5 days

Re: [PATCH v9 00/13] Add dmabuf read/write via io_uring

by Christoph Hellwig

On Mon, Oct 12, 2026 at 02:21:41PM -0600, Jens Axboe wrote: > I've queued this series up for some testing, in a separate branch. JFYI. More testing it obviously good. I've been waiting for addressing of the Sashiko comments on the nvme patches before doing more ACKs, and while I can't really judge the code those in the dma-buf code also look somewhat serious. So it would be useful to get them addressed and the series reposted. Same for folding in the PI vs dmabuf fix from Anuj, although making the combination work would of course be even better.

1 week, 6 days

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig October 2026