Linaro-mm-sig January 2026

linaro-mm-sig@lists.linaro.org

17 participants
44 discussions

Re: [PATCH rdma-next 2/2] RDMA/mlx5: Implement DMABUF export ops

by Jason Gunthorpe

On Thu, Jan 08, 2026 at 01:11:15PM +0200, Edward Srouji wrote: > +static int phys_addr_to_bar(struct pci_dev *pdev, phys_addr_t pa) > +{ > + resource_size_t start, end; > + int bar; > + > + for (bar = 0; bar < PCI_STD_NUM_BARS; bar++) { > + /* Skip BARs not present or not memory-mapped */ > + if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) > + continue; > + > + start = pci_resource_start(pdev, bar); > + end = pci_resource_end(pdev, bar); > + > + if (!start || !end) > + continue; > + > + if (pa >= start && pa <= end) > + return bar; > + } Don't we know which of the two BARs the mmap entry came from based on its type? This seems like overkill.. Jason

1 day, 16 hours

[PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers

by Leon Romanovsky

Changelog: v2: * Changed series to document the revoke semantics instead of implementing it. v1: https://patch.msgid.link/20260111-dmabuf-revoke-v1-0-fb4bcc8c259b@nvidia.com ------------------------------------------------------------------------- This series documents a dma-buf “revoke” mechanism: to allow a dma-buf exporter to explicitly invalidate (“kill”) a shared buffer after it has been distributed to importers, so that further CPU and device access is prevented and importers reliably observe failure. The change in this series is to properly document and use existing core “revoked” state on the dma-buf object and a corresponding exporter-triggered revoke operation. Once a dma-buf is revoked, new access paths are blocked so that attempts to DMA-map, vmap, or mmap the buffer fail in a consistent way. Thanks Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: linux-kernel(a)vger.kernel.org Cc: amd-gfx(a)lists.freedesktop.org Cc: virtualization(a)lists.linux.dev Cc: intel-xe(a)lists.freedesktop.org Cc: linux-rdma(a)vger.kernel.org Cc: iommu(a)lists.linux.dev Cc: kvm(a)vger.kernel.org To: Sumit Semwal <sumit.semwal(a)linaro.org> To: Christian König <christian.koenig(a)amd.com> To: Alex Deucher <alexander.deucher(a)amd.com> To: David Airlie <airlied(a)gmail.com> To: Simona Vetter <simona(a)ffwll.ch> To: Gerd Hoffmann <kraxel(a)redhat.com> To: Dmitry Osipenko <dmitry.osipenko(a)collabora.com> To: Gurchetan Singh <gurchetansingh(a)chromium.org> To: Chia-I Wu <olvaffe(a)gmail.com> To: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> To: Maxime Ripard <mripard(a)kernel.org> To: Thomas Zimmermann <tzimmermann(a)suse.de> To: Lucas De Marchi <lucas.demarchi(a)intel.com> To: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> To: Rodrigo Vivi <rodrigo.vivi(a)intel.com> To: Jason Gunthorpe <jgg(a)ziepe.ca> To: Leon Romanovsky <leon(a)kernel.org> To: Kevin Tian <kevin.tian(a)intel.com> To: Joerg Roedel <joro(a)8bytes.org> To: Will Deacon <will(a)kernel.org> To: Robin Murphy <robin.murphy(a)arm.com> To: Alex Williamson <alex(a)shazbot.org> --- Leon Romanovsky (4): dma-buf: Rename .move_notify() callback to a clearer identifier dma-buf: Document revoke semantics iommufd: Require DMABUF revoke semantics vfio: Add pinned interface to perform revoke semantics drivers/dma-buf/dma-buf.c | 6 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++-- drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +- drivers/gpu/drm/xe/tests/xe_dma_buf.c | 6 +++--- drivers/gpu/drm/xe/xe_dma_buf.c | 2 +- drivers/infiniband/core/umem_dmabuf.c | 4 ++-- drivers/infiniband/hw/mlx5/mr.c | 2 +- drivers/iommu/iommufd/pages.c | 11 +++++++++-- drivers/vfio/pci/vfio_pci_dmabuf.c | 16 ++++++++++++++++ include/linux/dma-buf.h | 25 ++++++++++++++++++++++--- 10 files changed, 60 insertions(+), 18 deletions(-) --- base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb change-id: 20251221-dmabuf-revoke-b90ef16e4236 Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

1 day, 21 hours

Independence for dma_fences! v6

by Christian König

Hi everyone, dma_fences have ever lived under the tyranny dictated by the module lifetime of their issuer, leading to crashes should anybody still holding a reference to a dma_fence when the module of the issuer was unloaded. The basic problem is that when buffer are shared between drivers dma_fence objects can leak into external drivers and stay there even after they are signaled. The dma_resv object for example only lazy releases dma_fences. So what happens is that when the module who originally created the dma_fence unloads the dma_fence_ops function table becomes unavailable as well and so any attempt to release the fence crashes the system. Previously various approaches have been discussed, including changing the locking semantics of the dma_fence callbacks (by me) as well as using the drm scheduler as intermediate layer (by Sima) to disconnect dma_fences from their actual users, but none of them are actually solving all problems. Tvrtko did some really nice prerequisite work by protecting the returned strings of the dma_fence_ops by RCU. This way dma_fence creators where able to just wait for an RCU grace period after fence signaling before they could be save to free those data structures. Now this patch set here goes a step further and protects the whole dma_fence_ops structure by RCU, so that after the fence signals the pointer to the dma_fence_ops is set to NULL when there is no wait nor release callback given. All functionality which use the dma_fence_ops reference are put inside an RCU critical section, except for the deprecated issuer specific wait and of course the optional release callback. Additional to the RCU changes the lock protecting the dma_fence state previously had to be allocated external. This set here now changes the functionality to make that external lock optional and allows dma_fences to use an inline lock and be self contained. v4: Rebases the whole set on upstream changes, especially the cleanup from Philip in patch "drm/amdgpu: independence for the amdkfd_fence!". Adding two patches which brings the DMA-fence self tests up to date. The first selftest changes removes the mock_wait and so actually starts testing the default behavior instead of some hacky implementation in the test. This one got upstreamed independent of this set. The second drops the mock_fence as well and tests the new RCU and inline spinlock functionality. v5: Rebase on top of drm-misc-next instead of drm-tip, leave out all driver changes for now since those should go through the driver specific paths anyway. Address a few more review comments, especially some rebase mess and typos. And finally fix one more bug found by AMDs CI system. v6: Minor style changes, re-ordered patch #1, dropped the scheduler fence change for now Please review and comment, Christian.

2 days

Re: [PATCH v3 0/2] dma-buf: system_heap: account for system heap allocation in memcg

by Maxime Ripard

On Fri, 16 Jan 2026 15:05:37 -0500, Eric Chanudet wrote: > Capture dmabuf system heap allocations in memcg following prior > conversations[1][2]. Disable this behavior by default unless configured > by "dma_heap.mem_accounting" module parameter. > > [1] https://lore.kernel.org/dri-devel/Z-5GZ3kJDbhgVBPG@phenom.ffwll.local/ > > [ ... ] Reviewed-by: Maxime Ripard <mripard(a)kernel.org> Thanks! Maxime

2 days, 21 hours

Re: [PATCH v3 1/2] dma-buf: heaps: add parameter to account allocations using cgroup

by T.J. Mercier

On Fri, Jan 16, 2026 at 12:06 PM Eric Chanudet <echanude(a)redhat.com> wrote: > > Add a parameter to enable dma-buf heaps allocation accounting using > cgroup for heaps that implement it. It is disabled by default as doing > so incurs caveats based on how memcg currently accounts for shared > buffers. > > Signed-off-by: Eric Chanudet <echanude(a)redhat.com> Reviewed-by: T.J. Mercier <tjmercier(a)google.com>

2 days, 22 hours

Re: [PATCH v3 2/2] dma-buf: system_heap: account for system heap allocation in memcg

by T.J. Mercier

On Fri, Jan 16, 2026 at 12:06 PM Eric Chanudet <echanude(a)redhat.com> wrote: > > The system dma-buf heap lets userspace allocate buffers from the page > allocator. However, these allocations are not accounted for in memcg, > allowing processes to escape limits that may be configured. > > Pass __GFP_ACCOUNT for system heap allocations, based on the > dma_heap.mem_accounting parameter, to use memcg and account for them. > > Signed-off-by: Eric Chanudet <echanude(a)redhat.com> Reviewed-by: T.J. Mercier <tjmercier(a)google.com>

2 days, 22 hours

Re: [PATCH v2 2/4] dma-buf: Document revoke semantics

by Leon Romanovsky

On Sun, Jan 18, 2026 at 11:32:20PM -0800, John Hubbard wrote: > On 1/18/26 11:25 PM, Leon Romanovsky wrote: > > On Sun, Jan 18, 2026 at 01:40:11PM -0800, John Hubbard wrote: > > > On 1/18/26 4:08 AM, Leon Romanovsky wrote: > > > > From: Leon Romanovsky <leonro(a)nvidia.com> > > > ... > > > > +/** > > > > + * dma_buf_attachment_is_revoke - check if a DMA-buf importer implements > > > > + * revoke semantics. > > > > + * @attach: the DMA-buf attachment to check > > > > + * > > > > + * Returns true if DMA-buf importer honors revoke semantics, which is > > > > + * negotiated with the exporter, by making sure that importer implements > > > > + * .invalidate_mappings() callback and calls to dma_buf_pin() after > > > > + * DMA-buf attach. > > > > + */ > > > > +static inline bool > > > > +dma_buf_attachment_is_revoke(struct dma_buf_attachment *attach) > > > > > > Maybe a slight rename, to dma_buf_attachment_is_revocable()? > > > > I can do that. The issue is that even "dma_buf_attachment_is_revoke" > > is already too long. :) > > > > If you're really pressed for space for some reason, Mainly aesthetics. > maybe dma_buf_attach_revocable() ? > > Just trying to hang on to the "revocable" part of the name, as > I think it's an improvement. Sure > > thanks, > -- > John Hubbard > >

3 days, 3 hours

Re: [PATCH v2 2/4] dma-buf: Document revoke semantics

by Leon Romanovsky

On Sun, Jan 18, 2026 at 01:40:11PM -0800, John Hubbard wrote: > On 1/18/26 4:08 AM, Leon Romanovsky wrote: > > From: Leon Romanovsky <leonro(a)nvidia.com> > ... > > +/** > > + * dma_buf_attachment_is_revoke - check if a DMA-buf importer implements > > + * revoke semantics. > > + * @attach: the DMA-buf attachment to check > > + * > > + * Returns true if DMA-buf importer honors revoke semantics, which is > > + * negotiated with the exporter, by making sure that importer implements > > + * .invalidate_mappings() callback and calls to dma_buf_pin() after > > + * DMA-buf attach. > > + */ > > +static inline bool > > +dma_buf_attachment_is_revoke(struct dma_buf_attachment *attach) > > Maybe a slight rename, to dma_buf_attachment_is_revocable()? I can do that. The issue is that even "dma_buf_attachment_is_revoke" is already too long. :) Thanks > > > thanks, > -- > John Hubbard >

3 days, 3 hours

Re: types: reuse common phys_vec type instead of DMABUF open‑coded variant

by Leon Romanovsky

On Fri, Jan 16, 2026 at 10:14:55AM -0700, Alex Williamson wrote: > On Wed, 14 Jan 2026 14:18:19 +0200 > Leon Romanovsky <leon(a)kernel.org> wrote: > > > On Wed, Jan 07, 2026 at 11:14:14AM +0200, Leon Romanovsky wrote: > > > From: Leon Romanovsky <leonro(a)nvidia.com> > > > > > > After commit fcf463b92a08 ("types: move phys_vec definition to common header"), > > > we can use the shared phys_vec type instead of the DMABUF‑specific > > > dma_buf_phys_vec, which duplicated the same structure and semantics. > > > > > > Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> > > > --- > > > Alex, > > > > > > According to diffstat, VFIO is the subsystem with the largest set of changes, > > > so it would be great if you could take it through your tree. > > > > > > The series is based on the for-7.0/blk-pvec shared branch from Jens: > > > https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git/log/?h=for-… > > > > > > Thanks > > > --- > > > > Alex, > > > > Could you please move this patch forward? We have the RDMA series [1] that > > depends on this rename, and I would like to base it on the shared branch. > > > > [1] https://lore.kernel.org/all/20260108-dmabuf-export-v1-0-6d47d46580d3@nvidia… > > I tried to ping Jens regarding why the branch with this code hasn't > been merged into their for-next branch, maybe you have more traction. It is in block/for-next now, commit df73d3c618b4 ("Merge branch 'for-7.0/blk-pvec' into for-7.0/block". Thanks > Thanks, > > Alex >

3 days, 18 hours

Re: [PATCH v2 0/2] dma-buf: system_heap: account for system heap allocation in memcg

by T.J. Mercier

On Tue, Jan 13, 2026 at 1:33 PM Eric Chanudet <echanude(a)redhat.com> wrote: > > Capture dmabuf system heap allocations in memcg following prior > conversations[1][2]. Disable this behavior by default unless configured > by "dma_heap.mem_accounting" module parameter. > > [1] https://lore.kernel.org/dri-devel/Z-5GZ3kJDbhgVBPG@phenom.ffwll.local/ > [2] https://lore.kernel.org/all/CABdmKX2_UOENujpW0dXe0Z0x+4V3onfGDmHf1DMOXfDha6… > > Changes in v2: > - Add a module parameter to enable dma-buf cgroup accounting, disabled > by default. > - Split system_heap logic in its own commit. > - Link to v1: https://lore.kernel.org/lkml/20251211193106.755485-2-echanude@redhat.com/ > > Signed-off-by: Eric Chanudet <echanude(a)redhat.com> > --- > Eric Chanudet (2): > dma-buf: heaps: add parameter to account allocations using cgroup > dma-buf: system_heap: account for system heap allocation in memcg > > drivers/dma-buf/dma-heap.c | 5 +++++ > drivers/dma-buf/heaps/system_heap.c | 9 +++++++-- > 2 files changed, 12 insertions(+), 2 deletions(-) > --- > base-commit: b71e635feefc852405b14620a7fc58c4c80c0f73 > change-id: 20260102-dmabuf-heap-system-memcg-c86a381d663a > > Best regards, > -- > Eric Chanudet <echanude(a)redhat.com> Thanks for adding the param, LGTM. Looking forward to v3.

5 days, 17 hours

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig January 2026