Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

13 participants
3696 discussions

Re: [RFC PATCH 0/3] dma-buf: warn-only mode for DMABUF_DEBUG

by Sumit Semwal

Hi Karl, On Tue, 13 Oct, 2026, 12:21 am Karl Mehltretter, <kmehltretter(a)gmail.com> wrote: > On Mon, Oct 12, 2026 at 10:12:02AM +0100, Thorsten Leemhuis wrote: > > > > What's the status here given that 7.3 will likely be released in a few > > days? Note, I can see from the discussion that this is a complex problem > > that can't be quickly solved. That's how it is sometimes. But I wonder > > if the current state of things is the best compromise for now or if > > Rob's revert or some other option would be better. > > > > I think reverting my commit 143755bdabaa ("dma-buf: Make DMABUF_DEBUG > default to y on DEBUG_KERNEL kernels") is the best interim solution for > v7.3. > > Christian, Sumit, could one of you apply Jianfeng's revert before the > final release? > > https://lore.kernel.org/r/20260926022026.10539-1-liujianfeng1994@gmail.com/ > > Ok, I'll try and revert it for 7.3. We may need to reapply it for the next cycle along with the solution Rob and folks are working on. Thanks, > Karl > Best, Sumit. >

3 weeks, 1 day

Re: [RFC PATCH v8 02/14] mm: Zero memory during shared memory transitions

by Aneesh Kumar K.V

Kiryl Shutsemau <kas(a)kernel.org> writes: > On Thu, Sep 24, 2026 at 03:35:17PM +0530, Aneesh Kumar K.V (Arm) wrote: >> diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c >> index f904a636d449..1f1f39082391 100644 >> --- a/arch/x86/coco/tdx/tdx.c >> +++ b/arch/x86/coco/tdx/tdx.c >> @@ -978,6 +978,9 @@ static bool tdx_enc_status_changed(unsigned long vaddr, int numpages, bool enc) >> static int tdx_enc_status_change_prepare(unsigned long vaddr, int numpages, >> bool enc) >> { >> + if (!enc) >> + memset((void *)vaddr, 0, (size_t)numpages << PAGE_SHIFT); >> + >> /* >> * Only handle shared->private conversion here. >> * See the comment in tdx_early_init(). > > This doesn't make sense to me. > > On TDX the memset zeroes a page that is about to be dropped. > MapGPA(shared) makes the VMM back the GPA with different memory, and > what the guest reads afterwards through the shared mapping is whatever > the host has there. > Does TDX require the guest contents to be preserved when pages are converted to shared? The memset() is done here because CoCo shared-memory allocations now ignore __GFP_ZERO and instead always zero the memory explicitly. For CoCo architectures such as CCA, this must be done after the memory is converted to shared because shared memory uses a different encryption context. The full patch avoids zeroing the memory twice. If __GFP_ZERO is used for a CoCo shared-page allocation, the page is first zeroed during allocation, then converted to shared, and must be zeroed again. I only changed Arm CCA in this series because I was unsure whether the other architectures required similar changes. Therefore, every CoCo architecture other than CCA currently performs the memset() before conversion, while CCA performs it afterward. If the host expects to see the guest contents from before the conversion to shared, we will have to pass the allocation flags down to these helpers and perform the memset() only when __GFP_ZERO was requested, along the lines of: https://lore.kernel.org/all/yq5aa4p82sqt.fsf@kernel.org To keep the changes minimal, the current approach always performs the memset() rather than passing down a flag. -aneesh

3 weeks, 1 day

Re: [PATCH] dma-buf: Annul dmabuf->file on file release

by Matt Evans

Hi Zack, On 07/10/2026 16:24, Zack Rusin wrote: > On Tue, Oct 6, 2026 at 3:15 PM Matt Evans <matt(a)ozlabs.org> wrote: >> >> The dmabuf release path is split between file and dentry release: >> dma_buf_file_release() is called shortly before the file is freed, and >> dma_buf_release() calls an exporter's dmabuf->ops->release when the >> dentry is freed. However, the dentry can outlive the file (for >> example, if opened with O_PATH), meaning .release might be called some >> time after the file is freed. >> >> This presents a window, when closing a DMABUF file, in which >> dmabuf->file points to freed memory yet .release op has not yet been >> called. >> >> For VFIO, if a buffer's .release has not been called it's considered >> still active and subject to move/cleanup. If so, it attempts to >> get_file_active() on dmabuf->file: a file close with dentry held open >> will call this function with a stale pointer, a UAF. >> >> To make this pattern safe, set dmabuf->file to NULL in >> dma_buf_file_release() to reflect that the associated file is now dead >> even if the DMABUF is not yet gone. A get_file_active() ... fput() >> sequence concurrent with a file close will only execute as one of: >> >> - Gets the file before file_ref_put() (dmabuf->file valid) >> - Observes dmabuf->file pointing to a file, but it's DEAD (no file) >> - Observes dmabuf->file = NULL (no file) >> >> Originally, drivers could assume dmabuf->file was valid until .release >> was called from fops->release. This assumption was no longer valid >> after 4ab59c3c638c6 ("dma-buf: Move dma_buf_release() from fops to >> dentry_ops"), which moved the callback to the dentry release (by which >> point the file might have been freed). With this commit, drivers must >> still consider that dmabuf->file could be NULL before .release. >> >> Fixes: 4ab59c3c638c6 ("dma-buf: Move dma_buf_release() from fops to dentry_ops") >> Signed-off-by: Matt Evans <matt(a)ozlabs.org> >> --- >> >> Hi, >> >> This issue was found (by Claude Opus 5.5) in the context of VFIO's >> DMABUF export path. VFIO iterates live DMABUFs with a >> get_file_active()/fput() block, which now becomes safe if the file is >> closed (and memory freed!) yet DMABUF .release hasn't yet occurred. >> >> However, there are a couple of other places that directly use >> dmabuf->file and seem able to race a closing file (i.e. without holding >> the file reference)? If this is so, they'd be a UAF today; with this >> patch that goes away, but instead of a stale pointer dmabuf->file could >> be NULL: >> >> 1. drivers/gpu/drm/vmwgfx/ttm_object.c:get_dma_buf_unless_doomed() >> >> file_ref_get(&dmabuf->file->f_ref); on a non-refcounted DMABUF > > Yes, that's a real UAF today. vmwgfx relied on the exporter's > dma_buf_ops.release running inside __fput() before file_free(), which > stopped being true with 4ab59c3c638c and we missed it. > > But this patch on its own makes vmwgfx worse. In the ordinary case, > where closing the file drops the last dentry reference, a close racing > PRIME_HANDLE_TO_FD is safe today: ttm_prime_dmabuf_release() runs from > the same __fput() and blocks on prime->mutex, keeping the file > allocated, so file_ref_get() just fails on the dead refcount. With > this patch dmabuf->file is NULL in that window and we oops. So this > shouldn't go to stable without a vmwgfx fix. > > For vmwgfx we'd probably need this one line change in > drivers/gpu/drm/vmwgfx/ttm_object.c to accompany this patch: > @@ -471,7 +475,7 @@ void ttm_object_device_release(struct > ttm_object_device **p_tdev) > */ > static bool __must_check get_dma_buf_unless_doomed(struct dma_buf *dmabuf) > { > - return file_ref_get(&dmabuf->file->f_ref); > + return get_file_active(&dmabuf->file) != NULL; > } > > under prime->mutex, which keeps the struct dma_buf alive. It needs the > NULL store from this patch to fix the existing UAF, since otherwise > the recheck can accept a recycled file through the unchanged stale > pointer. Thanks for confirming! Ah, so get_file_active() is good here, cheers. I'll repost as a 2-part series to first include this in vmwgfx and second add the anNULL. >> The commit message of 90ee6ed776c0 ("fs: port files to file_ref") hints >> this might be more subtle than replacing it with a get_file() variant >> (so as to accept a NULL file *). >> >> 2. drivers/gpu/drm/i915/gvt/dmabuf.c:intel_vgpu_get_dmabuf() >> >> gvt_dbg_dpy(... file_count(dmabuf->file) ...); FWIW aside, I re-read this, and there does appear to be a ref held (dma_buf_export() has just happened, and dma_buf_fd() generated) so dmabuf->file is stable at that point. >> Respective vmwgfx & i915 maintainers, what is your view? >> Or, indeed, if anyone sees any other questionable uses of dmabuf->file. >> >> Thanks, >> >> >> Matt >> >> >> drivers/dma-buf/dma-buf.c | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c >> index 4c9add51f9ef..726639130477 100644 >> --- a/drivers/dma-buf/dma-buf.c >> +++ b/drivers/dma-buf/dma-buf.c >> @@ -193,11 +193,15 @@ static void dma_buf_release(struct dentry *dentry) >> >> static int dma_buf_file_release(struct inode *inode, struct file *file) >> { >> + struct dma_buf *dmabuf = file->private_data; >> + >> if (!is_dma_buf_file(file)) >> return -EINVAL; >> >> - __dma_buf_list_del(file->private_data); >> + __dma_buf_list_del(dmabuf); >> >> + /* Must be observed by __get_file_rcu() before file_free() */ >> + smp_store_mb(dmabuf->file, NULL); > > I think Alex is right and dmabuf can be NULL here. An early if > (!dmabuf) return 0" will fix that. Yep, on it. Many thanks, Matt

3 weeks, 2 days

Re: [RFC PATCH 2/6] dma-buf: Add get_phys() to describe a physical run

by Christian König

On 10/5/26 15:20, Fred Griffoul wrote: > On 10/5/26 Christian König wrote: >> Well filling page tables by the importer is an absolutely clear NO-GO >> for the DMA-buf design, we have gotten down that path already and it >> took us years to remove this functionality again. > > Understood, thanks for the quick and clear answers on this patch and on > patch 3. > >> The problem you are facing here is that dma_buf_mmap() doesn't work >> because you don't have a VMA. > > Right: the memory has no struct page and is deliberately not mapped in > the host, so there is no VMA to hand to KVM. > > I'll post a new version of this series. It drops get_phys(), the ranged > invalidation and the guest_memfd dma-buf import (patches 2-5), and it > does not touch drivers/dma-buf, as you suggested in the PAL discussion: > > https://lore.kernel.org/all/c413710b-4c28-4ed8-88ec-aeb8c4482011@amd.com/ > > KVM gets its frames through the KVM-private guest_memfd provider > interface from David's series. iommufd gets them through a private > interface with the exporter, as it already does for vfio-pci. The new > version adds a small registry in iommufd for that, which replaces the > symbol_get() of the sample in David's series. The dma-buf is then only > the handle and the existing revoke. Yeah that approach sounds totally sane to me. We have drivers which stuff all kind of resources, not just memory, into a DMA-buf. That ranges from MMIO BARs to trigger FW operations (doorbells) over full HW blocks (ordered appends, global wave sync etc...) where two or more applications need to share which one is used. That you then have a exporter private interface is for accessing this is perfectly ok. The problem you are facing here is more that this is not limited to one driver/module but multiple ones and you don't want module inter dependencies because of the symbols. So symbol_get() is probably the right thing to do as long as we don't have something like weak symbols or similar. Regards, Christian. > > Thanks, > Fred

3 weeks, 2 days

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

by Matthew Brost

On Wed, Oct 07, 2026 at 02:42:44AM +0100, 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. > Full disclosure Pavel incorporated some of my ideas wrt to locking cleanup which I shared off the list. So I can't in fairness give an RB but: Acked-by: Matthew Brost <matthew.brost(a)intel.com> For the series - I can give this and I have pulled to code + have Xe nvme + IGT setup showing this working: Tested-by: Matthew Brost <matthew.brost(a)intel.com> > Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com> > --- > drivers/dma-buf/Makefile | 2 +- > drivers/dma-buf/dma-buf-io.c | 183 +++++++++++++++++++++++++++++++++++ > include/linux/dma-buf-io.h | 105 ++++++++++++++++++++ > include/linux/fs.h | 2 + > 4 files changed, 291 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..9ba9c17f900a > --- /dev/null > +++ b/drivers/dma-buf/dma-buf-io.c > @@ -0,0 +1,183 @@ > +/* 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) > +{ > + 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; > +} > + > +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); > +} > + > +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; > +} > + > +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); > +} > + > +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"); > + > +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..8ac338df51ff > --- /dev/null > +++ b/include/linux/dma-buf-io.h > @@ -0,0 +1,105 @@ > +/* 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; > +} > + > +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); > +} > + > +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 */ > -- > 2.54.0 >

3 weeks, 2 days

[PATCH v10 00/18] 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 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 (18): 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 | 81 +++ drivers/pci/Kconfig | 15 + drivers/pci/Makefile | 1 + drivers/pci/p2pdma.c | 719 ++++++++++++++++++-- drivers/pci/pci.c | 7 +- drivers/pci/pci.h | 56 ++ drivers/pci/pci_acs_test.c | 860 ++++++++++++++++++++++++ drivers/pci/quirks.c | 6 +- include/linux/pci-p2pdma.h | 12 +- 10 files changed, 1683 insertions(+), 85 deletions(-) --- base-commit: 36038f0e8377ef316b723d0d85b1510bc64069ab change-id: 20260821-fix-p2p-acs-v4-0-e72455e3a261 Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

3 weeks, 2 days

[PATCH 0/2] drm/syncobj: fix sync_file import into timeline points

by Julian Orth

Importing a sync_file into a timeline point (DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE | DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_TIMELINE) has two bugs since c2d3a7300695: 1. The fence and syncobj references leak if dma_fence_chain_alloc() fails. 2. A sync_file that contains a dma_fence_chain (e.g. one exported from a timeline point) is wrapped in another chain and triggers the WARN_ON in dma_fence_chain_init(). I reported this on 2026-05-20. These patches were developed completely autonomously by AI. I have reviewed them, but they have not been tested at runtime. They are only compile-tested. Julian Orth (2): drm/syncobj: fix fence and syncobj leak in drm_syncobj_import_sync_file_fence drm/syncobj: flatten chains when importing sync_file into timeline point drivers/gpu/drm/drm_syncobj.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) base-commit: 6ccf996a0dec1852dab94ad865f27b4904750e12 -- 2.56.0

3 weeks, 2 days

Re: [PATCH 3/3] dma-buf: heaps: cma: respect the device's maximum segment size

by Jason Gunthorpe

On Mon, Oct 05, 2026 at 08:46:40AM +0200, Karl Mehltretter wrote: > diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c > index 3fb4b946c91a..9d61d14688b8 100644 > --- a/drivers/dma-buf/heaps/cma_heap.c > +++ b/drivers/dma-buf/heaps/cma_heap.c > @@ -58,16 +58,22 @@ static int cma_heap_attach(struct dma_buf *dmabuf, > { > struct cma_heap_buffer *buffer = dmabuf->priv; > struct dma_heap_attachment *a; > + unsigned int max_segment; > int ret; > > + max_segment = dma_get_max_seg_size(attachment->dev); > + /* The SG allocator requires a segment limit of at least PAGE_SIZE. */ > + if (max_segment < PAGE_SIZE) > + return -EINVAL; This seems like unnecessary AI paranoia.. If something like this should exist it should be inside sg_alloc_table_from_pages_segment(). I guess pretty much every DRM user has this latent issue? Given few importers even seem to use the segment size, it would be nicer to solve it by just not using segment size here. This is possible with the new dma api, and adding a new dma_buf_pages_to_sgt() using that approach looked OK from an AI draft. However, the dma_sync_sgtable_for_device() in the heap doesn't seem to have a straightforward conversion.. We never made streaming functions for the new dma api, and drivers are not permitted to call the cache flushing functions by themselves. Something to think about at least. Jason

3 weeks, 5 days

Re: [RFC PATCH 1/2] iommu: Add iommu_map_sgtable_dma()

by Jason Gunthorpe

On Fri, Oct 09, 2026 at 02:21:13AM +0200, Karl Mehltretter wrote: > DMA-BUF attachments provide DMA addresses, not CPU-side pages. > iommu_map_sgtable() needs those pages, so private-domain importers such > as Rockchip cannot use it with strict DMABUF_DEBUG. > > Add an iommu-dma helper to map a live attachment into another domain by > translating through the device's default DMA domain. Roll back target > mappings on error. This still recovers physical addresses > internally. Absolutely not. You cannot recover the phys_addr's from a DMABUF expoter by using iommu_iova_to_phys(). Christian is adamant that drivers must not use physical addresses, and I will not agree to any hacks like this to try to end-run around his prohibition by abusing iommu subsystem. NAKed-by: Jason Gunthorpe <jgg(a)nvidia.com> If you want to keep the domain in the rockchip driver you have to fix DMABUF to allow an importer to use an iommu domain safely. It *must not* be done with a scatterlist interface, sorry, I know that is alot of work but Alistair is going to take a serious stab at it. Many users want this, not just rockchip. So help with the work to allow iommufd to do this and you will get it for free. Jason

3 weeks, 5 days

Re: [RFC PATCH 2/3] dma-buf: add a warn-only mode to DMABUF_DEBUG

by Jason Gunthorpe

On Wed, Oct 07, 2026 at 02:02:31PM +0200, Diederik de Haas wrote: > [ 1091.981354] rc rc3: two consecutive events of type space > [ 1104.670513] input: EDIFIER e235 (AVRCP) as /devices/virtual/input/input12 > [ 1172.090231] devfreq fb000000.gpu: Couldn't update frequency transition information. > [ 1189.403278] devfreq fb000000.gpu: Couldn't update frequency transition information. > [ 1206.309295] input: EDIFIER e235 (AVRCP) as /devices/virtual/input/input13 > [ 1268.968696] DMA-BUF: importer used the CPU side of an exporter's sg_table This is a nice stack trace, is that the point of this series? > [ 1268.968710] CPU: 6 UID: 1000 PID: 29025 Comm: sway Not tainted 7.3-rc6+unreleased-arm64-cknow #1 PREEMPTLAZY Debian 7.3~rc6-3 > [ 1268.968715] Hardware name: FriendlyElec NanoPC-T6 Plus (DT) > [ 1268.968717] Call trace: > [ 1268.968719] show_stack+0x20/0x38 (C) > [ 1268.968726] dump_stack_lvl+0x60/0x80 > [ 1268.968730] sg_dmabuf_cpu_access_warn.part.0+0x24/0x30 > [ 1268.968734] sg_dmabuf_cpu_access_warn+0x34/0x38 > [ 1268.968739] iommu_map_sg+0xc8/0x1e0 > [ 1268.968745] rockchip_gem_iommu_map+0x8c/0x128 [rockchipdrm] > [ 1268.968757] rockchip_gem_prime_import_sg_table+0x58/0x160 [rockchipdrm] > [ 1268.968761] drm_gem_prime_import_dev+0xa8/0x1d0 [drm] > [ 1268.968776] drm_gem_prime_fd_to_handle+0x1a4/0x280 [drm] So.. This is the exact same thing I need for iommufd. rockchip is managing its own iommu domain and you cannot map to an iommu domain without using a physical address. Of course it is *completely* illegal to call iommu_map_sgtable() in the importer side of a dmabuf. static int rockchip_gem_iommu_map(struct rockchip_gem_object *rk_obj) { [..] ret = iommu_map_sgtable(private->domain, rk_obj->dma_addr, rk_obj->sgt, prot); Jason

3 weeks, 5 days

← Newer
1
...
5
6
7
8
9
10
11
...
370
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig