[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260204121354.GH6771@unreal>
Date: Wed, 4 Feb 2026 14:13:54 +0200
From: Leon Romanovsky <leon@...nel.org>
To: Maxime Ripard <mripard@...nel.org>
Cc: Christian König <christian.koenig@....com>,
Sumit Semwal <sumit.semwal@...aro.org>,
Alex Deucher <alexander.deucher@....com>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Gerd Hoffmann <kraxel@...hat.com>,
Dmitry Osipenko <dmitry.osipenko@...labora.com>,
Gurchetan Singh <gurchetansingh@...omium.org>,
Chia-I Wu <olvaffe@...il.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Thomas Zimmermann <tzimmermann@...e.de>,
Lucas De Marchi <lucas.demarchi@...el.com>,
Thomas Hellström <thomas.hellstrom@...ux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
Jason Gunthorpe <jgg@...pe.ca>, Kevin Tian <kevin.tian@...el.com>,
Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
Robin Murphy <robin.murphy@....com>,
Felix Kuehling <Felix.Kuehling@....com>,
Alex Williamson <alex@...zbot.org>,
Ankit Agrawal <ankita@...dia.com>,
Vivek Kasireddy <vivek.kasireddy@...el.com>,
linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org,
linaro-mm-sig@...ts.linaro.org, linux-kernel@...r.kernel.org,
amd-gfx@...ts.freedesktop.org, virtualization@...ts.linux.dev,
intel-xe@...ts.freedesktop.org, linux-rdma@...r.kernel.org,
iommu@...ts.linux.dev, kvm@...r.kernel.org
Subject: Re: [PATCH v7 0/8] dma-buf: Use revoke mechanism to invalidate
shared buffers
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.
Thanks
>
> Maxime
Powered by blists - more mailing lists