From: Leon Romanovsky <leonro@nvidia.com>
DMABUF_MOVE_NOTIFY was introduced in 2018 and has been marked as
experimental and disabled by default ever since. Six years later,
all new importers implement this callback.
It is therefore reasonable to drop CONFIG_DMABUF_MOVE_NOTIFY and
always build DMABUF with support for it enabled.
Suggested-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
drivers/dma-buf/Kconfig | 12 ------------
drivers/dma-buf/dma-buf.c | 3 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 10 +++-------
drivers/gpu/drm/amd/amdkfd/Kconfig | 2 +-
drivers/gpu/drm/xe/tests/xe_dma_buf.c | 3 +--
drivers/gpu/drm/xe/xe_dma_buf.c | 12 ++++--------
6 files changed, 10 insertions(+), 32 deletions(-)
diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index b46eb8a552d7..84d5e9b24e20 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -40,18 +40,6 @@ config UDMABUF
A driver to let userspace turn memfd regions into dma-bufs.
Qemu can use this to create host dmabufs for guest framebuffers.
-config DMABUF_MOVE_NOTIFY
- bool "Move notify between drivers (EXPERIMENTAL)"
- default n
- depends on DMA_SHARED_BUFFER
- help
- Don't pin buffers if the dynamic DMA-buf interface is available on
- both the exporter as well as the importer. This fixes a security
- problem where userspace is able to pin unrestricted amounts of memory
- through DMA-buf.
- This is marked experimental because we don't yet have a consistent
- execution context and memory management between drivers.
-
config DMABUF_DEBUG
bool "DMA-BUF debug checks"
depends on DMA_SHARED_BUFFER
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index e12db540c413..cd68c1c0bfd7 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -847,8 +847,7 @@ static bool
dma_buf_pin_on_map(struct dma_buf_attachment *attach)
{
return attach->dmabuf->ops->pin &&
- (!dma_buf_attachment_is_dynamic(attach) ||
- !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY));
+ !dma_buf_attachment_is_dynamic(attach);
}
/**
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index cd4944ceb047..b7f85b8653cf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -133,13 +133,9 @@ static int amdgpu_dma_buf_pin(struct dma_buf_attachment *attach)
* notifiers are disabled, only allow pinning in VRAM when move
* notiers are enabled.
*/
- if (!IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) {
- domains &= ~AMDGPU_GEM_DOMAIN_VRAM;
- } else {
- list_for_each_entry(attach, &dmabuf->attachments, node)
- if (!attach->peer2peer)
- domains &= ~AMDGPU_GEM_DOMAIN_VRAM;
- }
+ list_for_each_entry(attach, &dmabuf->attachments, node)
+ if (!attach->peer2peer)
+ domains &= ~AMDGPU_GEM_DOMAIN_VRAM;
if (domains & AMDGPU_GEM_DOMAIN_VRAM)
bo->flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig b/drivers/gpu/drm/amd/amdkfd/Kconfig
index 16e12c9913f9..a5d7467c2f34 100644
--- a/drivers/gpu/drm/amd/amdkfd/Kconfig
+++ b/drivers/gpu/drm/amd/amdkfd/Kconfig
@@ -27,7 +27,7 @@ config HSA_AMD_SVM
config HSA_AMD_P2P
bool "HSA kernel driver support for peer-to-peer for AMD GPU devices"
- depends on HSA_AMD && PCI_P2PDMA && DMABUF_MOVE_NOTIFY
+ depends on HSA_AMD && PCI_P2PDMA
help
Enable peer-to-peer (P2P) communication between AMD GPUs over
the PCIe bus. This can improve performance of multi-GPU compute
diff --git a/drivers/gpu/drm/xe/tests/xe_dma_buf.c b/drivers/gpu/drm/xe/tests/xe_dma_buf.c
index 1f2cca5c2f81..c107687ef3c0 100644
--- a/drivers/gpu/drm/xe/tests/xe_dma_buf.c
+++ b/drivers/gpu/drm/xe/tests/xe_dma_buf.c
@@ -22,8 +22,7 @@ static bool p2p_enabled(struct dma_buf_test_params *params)
static bool is_dynamic(struct dma_buf_test_params *params)
{
- return IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY) && params->attach_ops &&
- params->attach_ops->invalidate_mappings;
+ return params->attach_ops && params->attach_ops->invalidate_mappings;
}
static void check_residency(struct kunit *test, struct xe_bo *exported,
diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c b/drivers/gpu/drm/xe/xe_dma_buf.c
index 1b9cd043e517..ea370cd373e9 100644
--- a/drivers/gpu/drm/xe/xe_dma_buf.c
+++ b/drivers/gpu/drm/xe/xe_dma_buf.c
@@ -56,14 +56,10 @@ static int xe_dma_buf_pin(struct dma_buf_attachment *attach)
bool allow_vram = true;
int ret;
- if (!IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) {
- allow_vram = false;
- } else {
- list_for_each_entry(attach, &dmabuf->attachments, node) {
- if (!attach->peer2peer) {
- allow_vram = false;
- break;
- }
+ list_for_each_entry(attach, &dmabuf->attachments, node) {
+ if (!attach->peer2peer) {
+ allow_vram = false;
+ break;
}
}
--
2.52.0
On 1/24/26 20:14, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.com>
>
> DMABUF_MOVE_NOTIFY was introduced in 2018 and has been marked as
> experimental and disabled by default ever since. Six years later,
> all new importers implement this callback.
>
> It is therefore reasonable to drop CONFIG_DMABUF_MOVE_NOTIFY and
> always build DMABUF with support for it enabled.
>
> Suggested-by: Christian König <christian.koenig@amd.com>
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
As long as nobody starts screaming in the last second or I encounter some other problem I'm going to push the first three patches to drm-misc-next now.
They are basically just cleanups we should have done a long time ago.
Regards,
Christian.
> ---
> drivers/dma-buf/Kconfig | 12 ------------
> drivers/dma-buf/dma-buf.c | 3 +--
> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 10 +++-------
> drivers/gpu/drm/amd/amdkfd/Kconfig | 2 +-
> drivers/gpu/drm/xe/tests/xe_dma_buf.c | 3 +--
> drivers/gpu/drm/xe/xe_dma_buf.c | 12 ++++--------
> 6 files changed, 10 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
> index b46eb8a552d7..84d5e9b24e20 100644
> --- a/drivers/dma-buf/Kconfig
> +++ b/drivers/dma-buf/Kconfig
> @@ -40,18 +40,6 @@ config UDMABUF
> A driver to let userspace turn memfd regions into dma-bufs.
> Qemu can use this to create host dmabufs for guest framebuffers.
>
> -config DMABUF_MOVE_NOTIFY
> - bool "Move notify between drivers (EXPERIMENTAL)"
> - default n
> - depends on DMA_SHARED_BUFFER
> - help
> - Don't pin buffers if the dynamic DMA-buf interface is available on
> - both the exporter as well as the importer. This fixes a security
> - problem where userspace is able to pin unrestricted amounts of memory
> - through DMA-buf.
> - This is marked experimental because we don't yet have a consistent
> - execution context and memory management between drivers.
> -
> config DMABUF_DEBUG
> bool "DMA-BUF debug checks"
> depends on DMA_SHARED_BUFFER
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index e12db540c413..cd68c1c0bfd7 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -847,8 +847,7 @@ static bool
> dma_buf_pin_on_map(struct dma_buf_attachment *attach)
> {
> return attach->dmabuf->ops->pin &&
> - (!dma_buf_attachment_is_dynamic(attach) ||
> - !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY));
> + !dma_buf_attachment_is_dynamic(attach);
> }
>
> /**
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> index cd4944ceb047..b7f85b8653cf 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> @@ -133,13 +133,9 @@ static int amdgpu_dma_buf_pin(struct dma_buf_attachment *attach)
> * notifiers are disabled, only allow pinning in VRAM when move
> * notiers are enabled.
> */
> - if (!IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) {
> - domains &= ~AMDGPU_GEM_DOMAIN_VRAM;
> - } else {
> - list_for_each_entry(attach, &dmabuf->attachments, node)
> - if (!attach->peer2peer)
> - domains &= ~AMDGPU_GEM_DOMAIN_VRAM;
> - }
> + list_for_each_entry(attach, &dmabuf->attachments, node)
> + if (!attach->peer2peer)
> + domains &= ~AMDGPU_GEM_DOMAIN_VRAM;
>
> if (domains & AMDGPU_GEM_DOMAIN_VRAM)
> bo->flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
> diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig b/drivers/gpu/drm/amd/amdkfd/Kconfig
> index 16e12c9913f9..a5d7467c2f34 100644
> --- a/drivers/gpu/drm/amd/amdkfd/Kconfig
> +++ b/drivers/gpu/drm/amd/amdkfd/Kconfig
> @@ -27,7 +27,7 @@ config HSA_AMD_SVM
>
> config HSA_AMD_P2P
> bool "HSA kernel driver support for peer-to-peer for AMD GPU devices"
> - depends on HSA_AMD && PCI_P2PDMA && DMABUF_MOVE_NOTIFY
> + depends on HSA_AMD && PCI_P2PDMA
> help
> Enable peer-to-peer (P2P) communication between AMD GPUs over
> the PCIe bus. This can improve performance of multi-GPU compute
> diff --git a/drivers/gpu/drm/xe/tests/xe_dma_buf.c b/drivers/gpu/drm/xe/tests/xe_dma_buf.c
> index 1f2cca5c2f81..c107687ef3c0 100644
> --- a/drivers/gpu/drm/xe/tests/xe_dma_buf.c
> +++ b/drivers/gpu/drm/xe/tests/xe_dma_buf.c
> @@ -22,8 +22,7 @@ static bool p2p_enabled(struct dma_buf_test_params *params)
>
> static bool is_dynamic(struct dma_buf_test_params *params)
> {
> - return IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY) && params->attach_ops &&
> - params->attach_ops->invalidate_mappings;
> + return params->attach_ops && params->attach_ops->invalidate_mappings;
> }
>
> static void check_residency(struct kunit *test, struct xe_bo *exported,
> diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c b/drivers/gpu/drm/xe/xe_dma_buf.c
> index 1b9cd043e517..ea370cd373e9 100644
> --- a/drivers/gpu/drm/xe/xe_dma_buf.c
> +++ b/drivers/gpu/drm/xe/xe_dma_buf.c
> @@ -56,14 +56,10 @@ static int xe_dma_buf_pin(struct dma_buf_attachment *attach)
> bool allow_vram = true;
> int ret;
>
> - if (!IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) {
> - allow_vram = false;
> - } else {
> - list_for_each_entry(attach, &dmabuf->attachments, node) {
> - if (!attach->peer2peer) {
> - allow_vram = false;
> - break;
> - }
> + list_for_each_entry(attach, &dmabuf->attachments, node) {
> + if (!attach->peer2peer) {
> + allow_vram = false;
> + break;
> }
> }
>
>
On Tue, Jan 27, 2026 at 10:26:26AM +0100, Christian König wrote: > On 1/24/26 20:14, Leon Romanovsky wrote: > > From: Leon Romanovsky <leonro@nvidia.com> > > > > DMABUF_MOVE_NOTIFY was introduced in 2018 and has been marked as > > experimental and disabled by default ever since. Six years later, > > all new importers implement this callback. > > > > It is therefore reasonable to drop CONFIG_DMABUF_MOVE_NOTIFY and > > always build DMABUF with support for it enabled. > > > > Suggested-by: Christian König <christian.koenig@amd.com> > > Signed-off-by: Leon Romanovsky <leonro@nvidia.com> > > Reviewed-by: Christian König <christian.koenig@amd.com> > > As long as nobody starts screaming in the last second or I encounter some other problem I'm going to push the first three patches to drm-misc-next now. How do you see progress of other patches? Can they be queued for that tree as well? Thanks > > They are basically just cleanups we should have done a long time ago. > > Regards, > Christian. >
On 1/27/26 10:58, Leon Romanovsky wrote: > On Tue, Jan 27, 2026 at 10:26:26AM +0100, Christian König wrote: >> On 1/24/26 20:14, Leon Romanovsky wrote: >>> From: Leon Romanovsky <leonro@nvidia.com> >>> >>> DMABUF_MOVE_NOTIFY was introduced in 2018 and has been marked as >>> experimental and disabled by default ever since. Six years later, >>> all new importers implement this callback. >>> >>> It is therefore reasonable to drop CONFIG_DMABUF_MOVE_NOTIFY and >>> always build DMABUF with support for it enabled. >>> >>> Suggested-by: Christian König <christian.koenig@amd.com> >>> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> >> >> Reviewed-by: Christian König <christian.koenig@amd.com> >> >> As long as nobody starts screaming in the last second or I encounter some other problem I'm going to push the first three patches to drm-misc-next now. > > How do you see progress of other patches? > Can they be queued for that tree as well? I was hoping to get through them by the end of the week. Just wanted to make sure that CI systems start to see the first three patches (who affect everybody), so that we get early feedback should we have missed something. Regards, Christian. > > Thanks > >> >> They are basically just cleanups we should have done a long time ago. >> >> Regards, >> Christian. >>
On Tue, Jan 27, 2026 at 11:02:03AM +0100, Christian König wrote: > On 1/27/26 10:58, Leon Romanovsky wrote: > > On Tue, Jan 27, 2026 at 10:26:26AM +0100, Christian König wrote: > >> On 1/24/26 20:14, Leon Romanovsky wrote: > >>> From: Leon Romanovsky <leonro@nvidia.com> > >>> > >>> DMABUF_MOVE_NOTIFY was introduced in 2018 and has been marked as > >>> experimental and disabled by default ever since. Six years later, > >>> all new importers implement this callback. > >>> > >>> It is therefore reasonable to drop CONFIG_DMABUF_MOVE_NOTIFY and > >>> always build DMABUF with support for it enabled. > >>> > >>> Suggested-by: Christian König <christian.koenig@amd.com> > >>> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> > >> > >> Reviewed-by: Christian König <christian.koenig@amd.com> > >> > >> As long as nobody starts screaming in the last second or I encounter some other problem I'm going to push the first three patches to drm-misc-next now. > > > > How do you see progress of other patches? > > Can they be queued for that tree as well? > > I was hoping to get through them by the end of the week. Christian, Can we please merge the whole series now? Thanks
On Tue, Jan 27, 2026 at 11:02:03AM +0100, Christian König wrote: > On 1/27/26 10:58, Leon Romanovsky wrote: > > On Tue, Jan 27, 2026 at 10:26:26AM +0100, Christian König wrote: > >> On 1/24/26 20:14, Leon Romanovsky wrote: > >>> From: Leon Romanovsky <leonro@nvidia.com> > >>> > >>> DMABUF_MOVE_NOTIFY was introduced in 2018 and has been marked as > >>> experimental and disabled by default ever since. Six years later, > >>> all new importers implement this callback. > >>> > >>> It is therefore reasonable to drop CONFIG_DMABUF_MOVE_NOTIFY and > >>> always build DMABUF with support for it enabled. > >>> > >>> Suggested-by: Christian König <christian.koenig@amd.com> > >>> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> > >> > >> Reviewed-by: Christian König <christian.koenig@amd.com> > >> > >> As long as nobody starts screaming in the last second or I encounter some other problem I'm going to push the first three patches to drm-misc-next now. > > > > How do you see progress of other patches? > > Can they be queued for that tree as well? > > I was hoping to get through them by the end of the week. > > Just wanted to make sure that CI systems start to see the first three patches (who affect everybody), so that we get early feedback should we have missed something. Perfect, I based my patches on these two commits: 61ceaf236115 (vfio/for-linus) vfio: Prevent from pinned DMABUF importers to attach to VFIO DMABUF 24d479d26b25 (tag: v6.19-rc6) Linux 6.19-rc6 Thanks > > Regards, > Christian. > > > > > Thanks > > > >> > >> They are basically just cleanups we should have done a long time ago. > >> > >> Regards, > >> Christian. > >> >
On Tue, Jan 27, 2026 at 01:42:43PM +0200, Leon Romanovsky wrote: > On Tue, Jan 27, 2026 at 11:02:03AM +0100, Christian König wrote: > > On 1/27/26 10:58, Leon Romanovsky wrote: > > > On Tue, Jan 27, 2026 at 10:26:26AM +0100, Christian König wrote: > > >> On 1/24/26 20:14, Leon Romanovsky wrote: > > >>> From: Leon Romanovsky <leonro@nvidia.com> > > >>> > > >>> DMABUF_MOVE_NOTIFY was introduced in 2018 and has been marked as > > >>> experimental and disabled by default ever since. Six years later, > > >>> all new importers implement this callback. > > >>> > > >>> It is therefore reasonable to drop CONFIG_DMABUF_MOVE_NOTIFY and > > >>> always build DMABUF with support for it enabled. > > >>> > > >>> Suggested-by: Christian König <christian.koenig@amd.com> > > >>> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> > > >> > > >> Reviewed-by: Christian König <christian.koenig@amd.com> > > >> > > >> As long as nobody starts screaming in the last second or I encounter some other problem I'm going to push the first three patches to drm-misc-next now. > > > > > > How do you see progress of other patches? > > > Can they be queued for that tree as well? > > > > I was hoping to get through them by the end of the week. > > > > Just wanted to make sure that CI systems start to see the first three patches (who affect everybody), so that we get early feedback should we have missed something. > > Perfect, I based my patches on these two commits: > 61ceaf236115 (vfio/for-linus) vfio: Prevent from pinned DMABUF importers to attach to VFIO DMABUF > 24d479d26b25 (tag: v6.19-rc6) Linux 6.19-rc6 The fix was merged https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1f97d9dcf53649c41c33227b345a36902cbb08ad Thanks > > Thanks > > > > > Regards, > > Christian. > > > > > > > > Thanks > > > > > >> > > >> They are basically just cleanups we should have done a long time ago. > > >> > > >> Regards, > > >> Christian. > > >> > > >
© 2016 - 2026 Red Hat, Inc.