Re: [PATCH v7 0/8] dma-buf: Use revoke mechanism to invalidate shared buffers

[Maxime Ripard]

On Wed, Feb 04, 2026 at 02:13:54PM +0200, Leon Romanovsky wrote:
> On Wed, Feb 04, 2026 at 01:01:54PM +0100, Maxime Ripard wrote:
> > On Wed, Feb 04, 2026 at 01:52:12PM +0200, Leon Romanovsky wrote:
> > > On Wed, Feb 04, 2026 at 09:56:08AM +0100, Maxime Ripard wrote:
> > > > On Wed, Feb 04, 2026 at 10:16:30AM +0200, Leon Romanovsky wrote:
> > > > > On Mon, Feb 02, 2026 at 06:04:25PM +0200, Leon Romanovsky wrote:
> > > > > > On Sat, Jan 31, 2026 at 07:34:10AM +0200, Leon Romanovsky wrote:
> > > > > > > Changelog:
> > > > > > > v7:
> > > > > > 
> > > > > > <...>
> > > > > > 
> > > > > > > Leon Romanovsky (8):
> > > > > > >       dma-buf: Rename .move_notify() callback to a clearer identifier
> > > > > > >       dma-buf: Rename dma_buf_move_notify() to dma_buf_invalidate_mappings()
> > > > > > >       dma-buf: Always build with DMABUF_MOVE_NOTIFY
> > > > > > >       vfio: Wait for dma-buf invalidation to complete
> > > > > > >       dma-buf: Make .invalidate_mapping() truly optional
> > > > > > >       dma-buf: Add dma_buf_attach_revocable()
> > > > > > >       vfio: Permit VFIO to work with pinned importers
> > > > > > >       iommufd: Add dma_buf_pin()
> > > > > > > 
> > > > > > >  drivers/dma-buf/Kconfig                     | 12 -----
> > > > > > >  drivers/dma-buf/dma-buf.c                   | 69 ++++++++++++++++++++-----
> > > > > > >  drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 14 ++---
> > > > > > >  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  |  2 +-
> > > > > > >  drivers/gpu/drm/amd/amdkfd/Kconfig          |  2 +-
> > > > > > >  drivers/gpu/drm/virtio/virtgpu_prime.c      |  2 +-
> > > > > > >  drivers/gpu/drm/xe/tests/xe_dma_buf.c       |  7 ++-
> > > > > > >  drivers/gpu/drm/xe/xe_bo.c                  |  2 +-
> > > > > > >  drivers/gpu/drm/xe/xe_dma_buf.c             | 14 ++---
> > > > > > >  drivers/infiniband/core/umem_dmabuf.c       | 13 -----
> > > > > > >  drivers/infiniband/hw/mlx5/mr.c             |  2 +-
> > > > > > >  drivers/iommu/iommufd/pages.c               | 11 +++-
> > > > > > >  drivers/iommu/iommufd/selftest.c            |  2 +-
> > > > > > >  drivers/vfio/pci/vfio_pci_dmabuf.c          | 80 ++++++++++++++++++++++-------
> > > > > > >  include/linux/dma-buf.h                     | 17 +++---
> > > > > > >  15 files changed, 153 insertions(+), 96 deletions(-)
> > > > > > 
> > > > > > Christian,
> > > > > > 
> > > > > > Given the ongoing discussion around patch v5, I'm a bit unclear on the
> > > > > > current state. Is the series ready for merging, or do you need me to
> > > > > > rework anything further?
> > > > > 
> > > > > Christian,
> > > > > 
> > > > > Let's not miss the merge window for work that is already ready.
> > > > 
> > > > The cutoff date for the merge window was on 25/1, so it was already
> > > > missed by the time you sent your series.
> > > 
> > > The primary goal of this series is to update dma-buf. The changes in
> > > drivers/gpu/drm are limited to straightforward renames.
> > 
> > And yet, dma-buf is maintained through drm.
> > 
> > Also, it's a general rule Linus has, it's nothing specific to DRM.
> 
> Can you point me to that general rule?
> 
> From what I have seen, subsystems such as netdev, the block layer, and RDMA continue
> to accept code that is ready for merging, especially when it has been thoroughly
> reviewed by multiple maintainers across different subsystems.

He said it multiple times, but here's one of such examples:

https://lore.kernel.org/all/CA+55aFwdd30eBsnMLB=ncExY0-P=eAsxkn_O6ir10JUyVSYdhA@xxxxxxxxxxxxxx/

And quoting:

> In particular, if you cannot follow the simple merge window rules
> (this whole two-week merge window and linux-next process has been in
> place over a decade), at least make the end result look good. Make it
> all look easy and problem-free.
>
> [...]
>
> Next merge window I will not accept anything even remotely like that.
> Things that haven't been in linux-next will be rejected

So, yeah, we can make exceptions. But you should ask and justify for
one, instead of expecting us to pick up a patch submission that was
already late.

Maxime

Attachment: signature.asc
Description: PGP signature