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