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(-)
Changelog:
v7:
* Fixed messed VFIO patch due to rebase.
v6: https://patch.msgid.link/20260130-dmabuf-revoke-v6-0-06278f9b7bf0@nvidia.com
* Added Reviewed-by tags.
* Changed for blocking wait_for_completion() in VFIO
* Fixed race between ->attach and move_notify, where priv->revoked is
flipped and lock is released.
v5: https://patch.msgid.link/20260124-dmabuf-revoke-v5-0-f98fca917e96@nvidia.com
* Documented the DMA-BUF expectations around DMA unmap.
* Added wait support in VFIO for DMA unmap.
* Reordered patches.
* Improved commit messages to document even more.
v4: https://lore.kernel.org/all/20260121-dmabuf-revoke-v4-0-d311cbc8633d@nvidia.com
* Changed DMA_RESV_USAGE_KERNEL to DMA_RESV_USAGE_BOOKKEEP.
* Made .invalidate_mapping() truly optional.
* Added patch which renames dma_buf_move_notify() to be
dma_buf_invalidate_mappings().
* Restored dma_buf_attachment_is_dynamic() function.
v3: https://lore.kernel.org/all/20260120-dmabuf-revoke-v3-0-b7e0b07b8214@nvidia.com/
* Used Jason's wordings for commits and cover letter.
* Removed IOMMUFD patch.
* Renamed dma_buf_attachment_is_revoke() to be dma_buf_attach_revocable().
* Added patch to remove CONFIG_DMABUF_MOVE_NOTIFY.
* Added Reviewed-by tags.
* Called to dma_resv_wait_timeout() after dma_buf_move_notify() in VFIO.
* Added dma_buf_attach_revocable() check to VFIO DMABUF attach function.
* Slightly changed commit messages.
v2: https://patch.msgid.link/20260118-dmabuf-revoke-v2-0-a03bb27c0875@nvidia.com
* 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 is based on latest VFIO fix, which will be sent to Linus
very soon.
https://lore.kernel.org/all/20260121-vfio-add-pin-v1-1-4e04916b17f1@nvidia.com/
Thanks
-------------------------------------------------------------------------
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.
dma-buf has quietly allowed calling move_notify on pinned dma-bufs, even
though legacy importers using dma_buf_attach() would simply ignore
these calls.
The intention was that move_notify() would tell the importer to expedite
it's unmapping process and once the importer is fully finished with DMA it
would unmap the dma-buf which finally signals that the importer is no
longer ever going to touch the memory again. Importers that touch past
their unmap() call can trigger IOMMU errors, AER and beyond, however
read-and-discard access between move_notify() and unmap is allowed.
Thus, we can define the exporter's revoke sequence for pinned dma-buf as:
dma_resv_lock(dmabuf->resv, NULL);
// Prevent new mappings from being established
priv->revoked = true;
// Tell all importers to eventually unmap
dma_buf_invalidate_mappings(dmabuf);
// Wait for any inprogress fences on the old mapping
dma_resv_wait_timeout(dmabuf->resv,
DMA_RESV_USAGE_BOOKKEEP, false,
MAX_SCHEDULE_TIMEOUT);
dma_resv_unlock(dmabuf->resv, NULL);
// Wait for all importers to complete unmap
wait_for_completion(&priv->unmapp_comp);
However, dma-buf also supports importers that don't do anything on
move_notify(), and will not unmap the buffer in bounded time.
Since such importers would cause the above sequence to hang, a new
mechanism is needed to detect incompatible importers.
Introduce dma_buf_attach_revocable() which if true indicates the above
sequence is safe to use and will complete in kernel-only bounded time for
this attachment.
Unfortunately dma_buf_attach_revocable() is going to fail for the popular
RDMA pinned importer, which means we cannot introduce it to existing
places using pinned move_notify() without potentially breaking existing
userspace flows.
Existing exporters that only trigger this flow for RAS errors should not
call dma_buf_attach_revocable() and will suffer an unbounded block on the
final completion, hoping that the userspace will notice the RAS and clean
things up. Without revoke support on the RDMA pinned importers it doesn't
seem like any other non-breaking option is currently possible.
For new exporters, like VFIO and RDMA, that have userspace triggered
revoke events, the unbouned sleep would not be acceptable. They can call
dma_buf_attach_revocable() and will not work with the RDMA pinned importer
from day 0, preventing regressions.
In the process add documentation explaining the above details.
Thanks
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
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(-)
---
base-commit: 61ceaf236115f20f4fdd7cf60f883ada1063349a
change-id: 20251221-dmabuf-revoke-b90ef16e4236
Best regards,
--
Leon Romanovsky <leonro@nvidia.com>
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? Thanks
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. Thanks > > Thanks >
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. Maxime
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. Thanks > > Maxime
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. Maxime
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
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@mail.gmail.com/ 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
On Wed, Feb 04, 2026 at 02:44:42PM +0100, Maxime Ripard wrote: > > 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@mail.gmail.com/ Woah, nobody is saying to skip linux-next. It is Wednesday, if it lands in the public tree today it will be in linux next probably for a week before a PR is sent. This is a fairly normal thing for many trees in Linux. Linus is specifically complaining about people *entirely* skipping linux-next. > 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. I think Leon is only pointing out that a hard cut off two weeks before the merge window even opens is a DRMism, not a kernel wide convention. Jason
On Wed, Feb 04, 2026 at 09:56:57AM -0400, Jason Gunthorpe wrote: > On Wed, Feb 04, 2026 at 02:44:42PM +0100, Maxime Ripard wrote: > > > 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@mail.gmail.com/ > > Woah, nobody is saying to skip linux-next. It is Wednesday, if it > lands in the public tree today it will be in linux next probably for a > week before a PR is sent. This is a fairly normal thing for many trees > in Linux. > > Linus is specifically complaining about people *entirely* skipping > linux-next. > > > 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. > > I think Leon is only pointing out that a hard cut off two weeks before > the merge window even opens is a DRMism, not a kernel wide convention. arm-soc has had the same kind of rule since pretty much forever too. Maxime
On Wed, Feb 04, 2026 at 09:56:57AM -0400, Jason Gunthorpe wrote: > On Wed, Feb 04, 2026 at 02:44:42PM +0100, Maxime Ripard wrote: > > > 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@mail.gmail.com/ > > Woah, nobody is saying to skip linux-next. It is Wednesday, if it > lands in the public tree today it will be in linux next probably for a > week before a PR is sent. This is a fairly normal thing for many trees > in Linux. > > Linus is specifically complaining about people *entirely* skipping > linux-next. Yes and yes. > > > 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. > > I think Leon is only pointing out that a hard cut off two weeks before > the merge window even opens is a DRMism, not a kernel wide convention. Correct. I would like to see it in linux-next as soon as possible, and to ensure I do not need to constantly rebase the patches because DRM changed something in the .move_notify() area. BTW, the series is in my tree: https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=dmabuf-revoke-v7 and is monitored by the kbuild bot, so this is not a random or untested submission. Thanks > > Jason >
On 2/4/26 09:16, 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. Mhm, sounds like AMDs mail servers never send my last mail out. As far as I can see all patches have an reviewed-by, I also gave an rb on patch #6 (should that mail never got out as well). The discussion on patch v5 is just orthogonal I think, the handling was there even completely before this patch set. For upstreaming as long as the VFIO and infiniband folks don't object I would like to take that through the drm-misc branch (like every other DMA-buf change). So as long as nobody objects I can push that today, but I can't promise that Dave/Linus will take it for the 6.20 window. Regards, Christian. > > Thanks > >> >> Thanks >>
On Wed, Feb 04, 2026 at 09:54:13AM +0100, Christian König wrote: > > Mhm, sounds like AMDs mail servers never send my last mail out. Oh :( > As far as I can see all patches have an reviewed-by, I also gave an > rb on patch #6 (should that mail never got out as well). The > discussion on patch v5 is just orthogonal I think, the handling was > there even completely before this patch set. Leon I guess grab the reviewed-by from this email and we have a full package if it needs a v8 > For upstreaming as long as the VFIO and infiniband folks don't > object I would like to take that through the drm-misc branch (like > every other DMA-buf change). No issue here, both subsystems are waiting for this.. > So as long as nobody objects I can push that today, but I can't > promise that Dave/Linus will take it for the 6.20 window. Sure, thanks, and if it doesn't happen for whatever reason lets just consider it pending for the next cycle. Next is to work on the dma mapping type, I should be able to post a rfc next week for people to look at. Thanks, Jason
On Wed, Feb 04, 2026 at 09:54:13AM +0100, Christian König wrote: > On 2/4/26 09:16, 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. > > Mhm, sounds like AMDs mail servers never send my last mail out. > > As far as I can see all patches have an reviewed-by, I also gave an rb on patch #6 (should that mail never got out as well). The discussion on patch v5 is just orthogonal I think, the handling was there even completely before this patch set. > > For upstreaming as long as the VFIO and infiniband folks don't object I would like to take that through the drm-misc branch (like every other DMA-buf change). Infiniband folks don't object :). > > So as long as nobody objects I can push that today, but I can't promise that Dave/Linus will take it for the 6.20 window. Let's give it a try, at the very least. Thanks > > Regards, > Christian. > > > > > Thanks > > > >> > >> Thanks > >> > >
On Wed, 4 Feb 2026 13:47:51 +0200 Leon Romanovsky <leon@kernel.org> wrote: > On Wed, Feb 04, 2026 at 09:54:13AM +0100, Christian König wrote: > > On 2/4/26 09:16, 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. > > > > Mhm, sounds like AMDs mail servers never send my last mail out. > > > > As far as I can see all patches have an reviewed-by, I also gave an rb on patch #6 (should that mail never got out as well). The discussion on patch v5 is just orthogonal I think, the handling was there even completely before this patch set. > > > > For upstreaming as long as the VFIO and infiniband folks don't object I would like to take that through the drm-misc branch (like every other DMA-buf change). > > Infiniband folks don't object :). No objection from vfio, I added one last R-b. Thanks, Alex
© 2016 - 2026 Red Hat, Inc.