[PATCH] Revert "dma-buf: Make DMABUF_DEBUG default to y on DEBUG_KERNEL kernels"

[PATCH] Revert "dma-buf: Make DMABUF_DEBUG default to y on DEBUG_KERNEL kernels"

[Jianfeng Liu]

This reverts commit 143755bdabaa96776c24f878014608e9cb44f930.

That commit fixed a dangling reference in the DMABUF_DEBUG default
and thereby enabled the option - and with it the page-stripping
sg_table wrapper that dma_buf_map_attachment() hands to importers -
on every kernel with DEBUG_KERNEL=y, i.e. virtually every distro
kernel.

drm/msm is broken by the wrapper.  Both of msm's map paths consume
sg->length and sg_phys() of the attachment sg_table:
msm_iommu_pagetable_map() for the per-process GPU pagetables, and
iommu_map_sg() (via iommu_map_sgtable()) for scanout.  The wrapper
zeroes sg->length and strips the page pointers, so mappings of
imported dma-bufs silently map nothing, and userspace observes
arm-smmu translation faults from UCHE, e.g. during hardware video
decode (clapper, chromium) on Adreno systems:

  gpu fault: ttbr0=000000088a889000 iova=000000010741c000 dir=READ
  type=TRANSLATION source=UCHE

Bisected on a Snapdragon X1E78100 laptop as v7.3-rc3 good,
v7.3-rc4 bad, culprit 143755bdabaa9.

Switching msm to sg_dma_address()/sg_dma_len() is not a trivial fix
either: those fields are only valid for sg_tables that msm has
dma-mapped itself, which native non-MSM_BO_WC objects' sg_tables
are not, so the conversion needs more work.  The msm maintainer has
therefore requested restoring the previous default for v7.3, to be
revisited once msm no longer consumes struct page and sg->length of
imported sg_tables.

Link: https://lore.kernel.org/linux-arm-msm/20260923074256.9357-1-liujianfeng1994@gmail.com/
Suggested-by: Rob Clark <robin.clark@oss.qualcomm.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Karl Mehltretter <kmehltretter@gmail.com>

Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com>
---

 drivers/dma-buf/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index e4f078a326a41..7efc0f0d07126 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -43,7 +43,7 @@ config UDMABUF
 config DMABUF_DEBUG
 	bool "DMA-BUF debug checks"
 	depends on DMA_SHARED_BUFFER
-	default y if DEBUG_KERNEL
+	default y if DEBUG
 	help
 	  This option enables additional checks for DMA-BUF importers and
 	  exporters. Specifically it validates that importers do not peek at the
---
base-commit: 93f51579e7df248780214094418f205253383cc5
branch: revert-dmabuf-debug-for-7.3

-- 
2.47.3

Re: [PATCH] Revert "dma-buf: Make DMABUF_DEBUG default to y on DEBUG_KERNEL kernels"

[Rob Clark]

On Fri, Sep 25, 2026 at 7:20 PM Jianfeng Liu <liujianfeng1994@gmail.com> wrote:
>
> This reverts commit 143755bdabaa96776c24f878014608e9cb44f930.
>
> That commit fixed a dangling reference in the DMABUF_DEBUG default
> and thereby enabled the option - and with it the page-stripping
> sg_table wrapper that dma_buf_map_attachment() hands to importers -
> on every kernel with DEBUG_KERNEL=y, i.e. virtually every distro
> kernel.
>
> drm/msm is broken by the wrapper.  Both of msm's map paths consume
> sg->length and sg_phys() of the attachment sg_table:
> msm_iommu_pagetable_map() for the per-process GPU pagetables, and
> iommu_map_sg() (via iommu_map_sgtable()) for scanout.  The wrapper
> zeroes sg->length and strips the page pointers, so mappings of
> imported dma-bufs silently map nothing, and userspace observes
> arm-smmu translation faults from UCHE, e.g. during hardware video
> decode (clapper, chromium) on Adreno systems:
>
>   gpu fault: ttbr0=000000088a889000 iova=000000010741c000 dir=READ
>   type=TRANSLATION source=UCHE
>
> Bisected on a Snapdragon X1E78100 laptop as v7.3-rc3 good,
> v7.3-rc4 bad, culprit 143755bdabaa9.
>
> Switching msm to sg_dma_address()/sg_dma_len() is not a trivial fix
> either: those fields are only valid for sg_tables that msm has
> dma-mapped itself, which native non-MSM_BO_WC objects' sg_tables
> are not, so the conversion needs more work.  The msm maintainer has
> therefore requested restoring the previous default for v7.3, to be
> revisited once msm no longer consumes struct page and sg->length of
> imported sg_tables.

I sent a series[1] to remove the remaining (direct) use of pages for
imported dma-bufs, and remove use of drm_prime_sg_to_page_array() (so
one less caller of the deprecated function).

This on its own won't solve the problems with CONFIG_DMABUF_DEBUG.
There is still the indirect dependency on pages when mapping sgt's.  I
won't have time to work on that until after XDC, so it won't be a v7.3
thing, and _probably_ won't be a v7.4 thing at this point.  But
hopefully I can come up with something for v7.5.  Until then, please
apply this revert.

BR,
-R

[1] https://patchwork.freedesktop.org/series/175045/

> Link: https://lore.kernel.org/linux-arm-msm/20260923074256.9357-1-liujianfeng1994@gmail.com/
> Suggested-by: Rob Clark <robin.clark@oss.qualcomm.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Sumit Semwal <sumit.semwal@linaro.org>
> Cc: Karl Mehltretter <kmehltretter@gmail.com>
>
> Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com>
> ---
>
>  drivers/dma-buf/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
> index e4f078a326a41..7efc0f0d07126 100644
> --- a/drivers/dma-buf/Kconfig
> +++ b/drivers/dma-buf/Kconfig
> @@ -43,7 +43,7 @@ config UDMABUF
>  config DMABUF_DEBUG
>         bool "DMA-BUF debug checks"
>         depends on DMA_SHARED_BUFFER
> -       default y if DEBUG_KERNEL
> +       default y if DEBUG
>         help
>           This option enables additional checks for DMA-BUF importers and
>           exporters. Specifically it validates that importers do not peek at the
> ---
> base-commit: 93f51579e7df248780214094418f205253383cc5
> branch: revert-dmabuf-debug-for-7.3
>
> --
> 2.47.3
>

Re: [PATCH] Revert "dma-buf: Make DMABUF_DEBUG default to y on DEBUG_KERNEL kernels"

[Christian König]

On 9/26/26 04:20, Jianfeng Liu wrote:
> That commit fixed a dangling reference in the DMABUF_DEBUG default
> and thereby enabled the option - and with it the page-stripping
> sg_table wrapper that dma_buf_map_attachment() hands to importers -
> on every kernel with DEBUG_KERNEL=y, i.e. virtually every distro
> kernel.
> 
> drm/msm is broken by the wrapper.  Both of msm's map paths consume
> sg->length and sg_phys() of the attachment sg_table:
> msm_iommu_pagetable_map() for the per-process GPU pagetables, and
> iommu_map_sg() (via iommu_map_sgtable()) for scanout.  The wrapper
> zeroes sg->length and strips the page pointers, so mappings of
> imported dma-bufs silently map nothing, and userspace observes
> arm-smmu translation faults from UCHE, e.g. during hardware video
> decode (clapper, chromium) on Adreno systems:
> 
>   gpu fault: ttbr0=000000088a889000 iova=000000010741c000 dir=READ
>   type=TRANSLATION source=UCHE
> 
> Bisected on a Snapdragon X1E78100 laptop as v7.3-rc3 good,
> v7.3-rc4 bad, culprit 143755bdabaa9.
> 
> Switching msm to sg_dma_address()/sg_dma_len() is not a trivial fix
> either: those fields are only valid for sg_tables that msm has
> dma-mapped itself, which native non-MSM_BO_WC objects' sg_tables
> are not, so the conversion needs more work.  The msm maintainer has
> therefore requested restoring the previous default for v7.3, to be
> revisited once msm no longer consumes struct page and sg->length of
> imported sg_tables.

Yeah as I said before the problematic part is MSM here. We have enforced correct driver behavior for over 5 years now when that option is enabled.

What we can do is to mark MSM as broken and/or give a warning in MSM when DMABUF_DEBUG is enabled and you try to import a DMA-buf.

But making the check not default to enable on debug kernels is not an option. This check here is exactly to point out broken drivers and you can manually disable it.

Regards,
Christian.

> 
> Link: https://lore.kernel.org/linux-arm-msm/20260923074256.9357-1-liujianfeng1994@gmail.com/
> Suggested-by: Rob Clark <robin.clark@oss.qualcomm.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Sumit Semwal <sumit.semwal@linaro.org>
> Cc: Karl Mehltretter <kmehltretter@gmail.com>
> 
> Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com>
> ---
> 
>  drivers/dma-buf/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
> index e4f078a326a41..7efc0f0d07126 100644
> --- a/drivers/dma-buf/Kconfig
> +++ b/drivers/dma-buf/Kconfig
> @@ -43,7 +43,7 @@ config UDMABUF
>  config DMABUF_DEBUG
>  	bool "DMA-BUF debug checks"
>  	depends on DMA_SHARED_BUFFER
> -	default y if DEBUG_KERNEL
> +	default y if DEBUG
>  	help
>  	  This option enables additional checks for DMA-BUF importers and
>  	  exporters. Specifically it validates that importers do not peek at the
> ---
> base-commit: 93f51579e7df248780214094418f205253383cc5
> branch: revert-dmabuf-debug-for-7.3
> 

Re: [PATCH] Revert "dma-buf: Make DMABUF_DEBUG default to y on DEBUG_KERNEL kernels"

[Rob Clark]

On Mon, Sep 28, 2026 at 1:19 AM Christian König
<christian.koenig@amd.com> wrote:
>
> On 9/26/26 04:20, Jianfeng Liu wrote:
> > That commit fixed a dangling reference in the DMABUF_DEBUG default
> > and thereby enabled the option - and with it the page-stripping
> > sg_table wrapper that dma_buf_map_attachment() hands to importers -
> > on every kernel with DEBUG_KERNEL=y, i.e. virtually every distro
> > kernel.
> >
> > drm/msm is broken by the wrapper.  Both of msm's map paths consume
> > sg->length and sg_phys() of the attachment sg_table:
> > msm_iommu_pagetable_map() for the per-process GPU pagetables, and
> > iommu_map_sg() (via iommu_map_sgtable()) for scanout.  The wrapper
> > zeroes sg->length and strips the page pointers, so mappings of
> > imported dma-bufs silently map nothing, and userspace observes
> > arm-smmu translation faults from UCHE, e.g. during hardware video
> > decode (clapper, chromium) on Adreno systems:
> >
> >   gpu fault: ttbr0=000000088a889000 iova=000000010741c000 dir=READ
> >   type=TRANSLATION source=UCHE
> >
> > Bisected on a Snapdragon X1E78100 laptop as v7.3-rc3 good,
> > v7.3-rc4 bad, culprit 143755bdabaa9.
> >
> > Switching msm to sg_dma_address()/sg_dma_len() is not a trivial fix
> > either: those fields are only valid for sg_tables that msm has
> > dma-mapped itself, which native non-MSM_BO_WC objects' sg_tables
> > are not, so the conversion needs more work.  The msm maintainer has
> > therefore requested restoring the previous default for v7.3, to be
> > revisited once msm no longer consumes struct page and sg->length of
> > imported sg_tables.
>
> Yeah as I said before the problematic part is MSM here. We have enforced correct driver behavior for over 5 years now when that option is enabled.

The problem is bigger than MSM here

> What we can do is to mark MSM as broken and/or give a warning in MSM when DMABUF_DEBUG is enabled and you try to import a DMA-buf.

sorry, no, we can't mark MSM as broken.. we can mark DMABUF_DEBUG as BROKEN

BR,
-R

> But making the check not default to enable on debug kernels is not an option. This check here is exactly to point out broken drivers and you can manually disable it.
>
> Regards,
> Christian.
>
> >
> > Link: https://lore.kernel.org/linux-arm-msm/20260923074256.9357-1-liujianfeng1994@gmail.com/
> > Suggested-by: Rob Clark <robin.clark@oss.qualcomm.com>
> > Cc: Christian König <christian.koenig@amd.com>
> > Cc: Sumit Semwal <sumit.semwal@linaro.org>
> > Cc: Karl Mehltretter <kmehltretter@gmail.com>
> >
> > Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com>
> > ---
> >
> >  drivers/dma-buf/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
> > index e4f078a326a41..7efc0f0d07126 100644
> > --- a/drivers/dma-buf/Kconfig
> > +++ b/drivers/dma-buf/Kconfig
> > @@ -43,7 +43,7 @@ config UDMABUF
> >  config DMABUF_DEBUG
> >       bool "DMA-BUF debug checks"
> >       depends on DMA_SHARED_BUFFER
> > -     default y if DEBUG_KERNEL
> > +     default y if DEBUG
> >       help
> >         This option enables additional checks for DMA-BUF importers and
> >         exporters. Specifically it validates that importers do not peek at the
> > ---
> > base-commit: 93f51579e7df248780214094418f205253383cc5
> > branch: revert-dmabuf-debug-for-7.3
> >
>

Re: [PATCH] Revert "dma-buf: Make DMABUF_DEBUG default to y on DEBUG_KERNEL kernels"

[Christian König]

On 9/28/26 12:36, Rob Clark wrote:
> On Mon, Sep 28, 2026 at 1:19 AM Christian König
> <christian.koenig@amd.com> wrote:
>>
>> On 9/26/26 04:20, Jianfeng Liu wrote:
>>> That commit fixed a dangling reference in the DMABUF_DEBUG default
>>> and thereby enabled the option - and with it the page-stripping
>>> sg_table wrapper that dma_buf_map_attachment() hands to importers -
>>> on every kernel with DEBUG_KERNEL=y, i.e. virtually every distro
>>> kernel.
>>>
>>> drm/msm is broken by the wrapper.  Both of msm's map paths consume
>>> sg->length and sg_phys() of the attachment sg_table:
>>> msm_iommu_pagetable_map() for the per-process GPU pagetables, and
>>> iommu_map_sg() (via iommu_map_sgtable()) for scanout.  The wrapper
>>> zeroes sg->length and strips the page pointers, so mappings of
>>> imported dma-bufs silently map nothing, and userspace observes
>>> arm-smmu translation faults from UCHE, e.g. during hardware video
>>> decode (clapper, chromium) on Adreno systems:
>>>
>>>   gpu fault: ttbr0=000000088a889000 iova=000000010741c000 dir=READ
>>>   type=TRANSLATION source=UCHE
>>>
>>> Bisected on a Snapdragon X1E78100 laptop as v7.3-rc3 good,
>>> v7.3-rc4 bad, culprit 143755bdabaa9.
>>>
>>> Switching msm to sg_dma_address()/sg_dma_len() is not a trivial fix
>>> either: those fields are only valid for sg_tables that msm has
>>> dma-mapped itself, which native non-MSM_BO_WC objects' sg_tables
>>> are not, so the conversion needs more work.  The msm maintainer has
>>> therefore requested restoring the previous default for v7.3, to be
>>> revisited once msm no longer consumes struct page and sg->length of
>>> imported sg_tables.
>>
>> Yeah as I said before the problematic part is MSM here. We have enforced correct driver behavior for over 5 years now when that option is enabled.
> 
> The problem is bigger than MSM here

Well, so far I have only heard about MSM.

But yes I mean the config option is doing exactly what it is supposed to do, pointing out when driver need some work to get this fixed.

I also agree that we shouldn't have allowed driver to touch that stuff in the first place and better document how to do things but yeah I can't change the past I can only try to fix it now.

>> What we can do is to mark MSM as broken and/or give a warning in MSM when DMABUF_DEBUG is enabled and you try to import a DMA-buf.
> 
> sorry, no, we can't mark MSM as broken.. we can mark DMABUF_DEBUG as BROKEN

As I wrote the debug functionality to enforce not using struct pages has been around for over 5 years now, it was just not enabled by default.

What I can offer is to set it to default N for another few month to give you more time to fix things.

Regards,
Christian.

> 
> BR,
> -R
> 
>> But making the check not default to enable on debug kernels is not an option. This check here is exactly to point out broken drivers and you can manually disable it.
>>
>> Regards,
>> Christian.
>>
>>>
>>> Link: https://lore.kernel.org/linux-arm-msm/20260923074256.9357-1-liujianfeng1994@gmail.com/
>>> Suggested-by: Rob Clark <robin.clark@oss.qualcomm.com>
>>> Cc: Christian König <christian.koenig@amd.com>
>>> Cc: Sumit Semwal <sumit.semwal@linaro.org>
>>> Cc: Karl Mehltretter <kmehltretter@gmail.com>
>>>
>>> Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com>
>>> ---
>>>
>>>  drivers/dma-buf/Kconfig | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
>>> index e4f078a326a41..7efc0f0d07126 100644
>>> --- a/drivers/dma-buf/Kconfig
>>> +++ b/drivers/dma-buf/Kconfig
>>> @@ -43,7 +43,7 @@ config UDMABUF
>>>  config DMABUF_DEBUG
>>>       bool "DMA-BUF debug checks"
>>>       depends on DMA_SHARED_BUFFER
>>> -     default y if DEBUG_KERNEL
>>> +     default y if DEBUG
>>>       help
>>>         This option enables additional checks for DMA-BUF importers and
>>>         exporters. Specifically it validates that importers do not peek at the
>>> ---
>>> base-commit: 93f51579e7df248780214094418f205253383cc5
>>> branch: revert-dmabuf-debug-for-7.3
>>>
>>

Re: [PATCH] Revert "dma-buf: Make DMABUF_DEBUG default to y on DEBUG_KERNEL kernels"

[Rob Clark]

On Mon, Sep 28, 2026 at 3:48 AM Christian König
<christian.koenig@amd.com> wrote:
>
> On 9/28/26 12:36, Rob Clark wrote:
> > On Mon, Sep 28, 2026 at 1:19 AM Christian König
> > <christian.koenig@amd.com> wrote:
> >>
> >> On 9/26/26 04:20, Jianfeng Liu wrote:
> >>> That commit fixed a dangling reference in the DMABUF_DEBUG default
> >>> and thereby enabled the option - and with it the page-stripping
> >>> sg_table wrapper that dma_buf_map_attachment() hands to importers -
> >>> on every kernel with DEBUG_KERNEL=y, i.e. virtually every distro
> >>> kernel.
> >>>
> >>> drm/msm is broken by the wrapper.  Both of msm's map paths consume
> >>> sg->length and sg_phys() of the attachment sg_table:
> >>> msm_iommu_pagetable_map() for the per-process GPU pagetables, and
> >>> iommu_map_sg() (via iommu_map_sgtable()) for scanout.  The wrapper
> >>> zeroes sg->length and strips the page pointers, so mappings of
> >>> imported dma-bufs silently map nothing, and userspace observes
> >>> arm-smmu translation faults from UCHE, e.g. during hardware video
> >>> decode (clapper, chromium) on Adreno systems:
> >>>
> >>>   gpu fault: ttbr0=000000088a889000 iova=000000010741c000 dir=READ
> >>>   type=TRANSLATION source=UCHE
> >>>
> >>> Bisected on a Snapdragon X1E78100 laptop as v7.3-rc3 good,
> >>> v7.3-rc4 bad, culprit 143755bdabaa9.
> >>>
> >>> Switching msm to sg_dma_address()/sg_dma_len() is not a trivial fix
> >>> either: those fields are only valid for sg_tables that msm has
> >>> dma-mapped itself, which native non-MSM_BO_WC objects' sg_tables
> >>> are not, so the conversion needs more work.  The msm maintainer has
> >>> therefore requested restoring the previous default for v7.3, to be
> >>> revisited once msm no longer consumes struct page and sg->length of
> >>> imported sg_tables.
> >>
> >> Yeah as I said before the problematic part is MSM here. We have enforced correct driver behavior for over 5 years now when that option is enabled.
> >
> > The problem is bigger than MSM here
>
> Well, so far I have only heard about MSM.
>
> But yes I mean the config option is doing exactly what it is supposed to do, pointing out when driver need some work to get this fixed.

It served its purpose, to expose some bigger issues.. but sadly those
are beyond just msm and not something that can be fixed quickly

> I also agree that we shouldn't have allowed driver to touch that stuff in the first place and better document how to do things but yeah I can't change the past I can only try to fix it now.
>
> >> What we can do is to mark MSM as broken and/or give a warning in MSM when DMABUF_DEBUG is enabled and you try to import a DMA-buf.
> >
> > sorry, no, we can't mark MSM as broken.. we can mark DMABUF_DEBUG as BROKEN
>
> As I wrote the debug functionality to enforce not using struct pages has been around for over 5 years now, it was just not enabled by default.
>
> What I can offer is to set it to default N for another few month to give you more time to fix things.

If it is disabled by default in distro kernels, that sounds fine.
I've cleaned up the remaining use of pages in msm (which were not load
bearing, but I should have done before to remove use of
drm_prime_sg_to_page_array()), but the problems extend further and is
a bit complicated because the hw uses SSMU in a way that dma-mapping
doesn't consider very well.

BR,
-R


> Regards,
> Christian.
>
> >
> > BR,
> > -R
> >
> >> But making the check not default to enable on debug kernels is not an option. This check here is exactly to point out broken drivers and you can manually disable it.
> >>
> >> Regards,
> >> Christian.
> >>
> >>>
> >>> Link: https://lore.kernel.org/linux-arm-msm/20260923074256.9357-1-liujianfeng1994@gmail.com/
> >>> Suggested-by: Rob Clark <robin.clark@oss.qualcomm.com>
> >>> Cc: Christian König <christian.koenig@amd.com>
> >>> Cc: Sumit Semwal <sumit.semwal@linaro.org>
> >>> Cc: Karl Mehltretter <kmehltretter@gmail.com>
> >>>
> >>> Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com>
> >>> ---
> >>>
> >>>  drivers/dma-buf/Kconfig | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
> >>> index e4f078a326a41..7efc0f0d07126 100644
> >>> --- a/drivers/dma-buf/Kconfig
> >>> +++ b/drivers/dma-buf/Kconfig
> >>> @@ -43,7 +43,7 @@ config UDMABUF
> >>>  config DMABUF_DEBUG
> >>>       bool "DMA-BUF debug checks"
> >>>       depends on DMA_SHARED_BUFFER
> >>> -     default y if DEBUG_KERNEL
> >>> +     default y if DEBUG
> >>>       help
> >>>         This option enables additional checks for DMA-BUF importers and
> >>>         exporters. Specifically it validates that importers do not peek at the
> >>> ---
> >>> base-commit: 93f51579e7df248780214094418f205253383cc5
> >>> branch: revert-dmabuf-debug-for-7.3
> >>>
> >>
>

Re: [PATCH] Revert "dma-buf: Make DMABUF_DEBUG default to y on DEBUG_KERNEL kernels"

[Karl Mehltretter]

On Mon, Sep 28, 2026 at 04:21:41AM +0100, Rob Clark wrote:
> On Mon, Sep 28, 2026 at 3:48 AM Christian König
> > What I can offer is to set it to default N for another few month to give you more time to fix things.
> 
> If it is disabled by default in distro kernels, that sounds fine.

Another option is to restore the earlier DMABUF_DEBUG default for now,
although off by default is also fine with me:

	default y if DMA_API_DEBUG

I would like to help fix the affected importers, and have started work
on several of them. Beyond msm, my LLM agent found paths that use the
page or CPU-length fields of imported attachment tables in:

  - rockchip, tegra, rcar-du/VSP, omapdrm and xen_drm_front;
  - tegra-vde, staging ipu3, pxa_camera and sur40;
  - fastrpc's SECUREMAP path;
  - the IIO dmaengine buffer, USB FunctionFS and UVC gadget DMABUF paths.

The host1x imported-buffer gather path also looks susceptible. There
are less severe cases too: amdxdna rejects the affected import, while
mali-dp loses MMU prefetch.

For sur40, IIO, FunctionFS and UVC gadget, I have reproduced failures
and tested local fixes in QEMU using local device models. The other
entries above are findings from source inspection, not hardware tests.
Some failures depend on the architecture and configuration, in
particular whether NEED_SG_DMA_LENGTH is enabled.

Unfortunately, I don't have hardware for most of these drivers...

I think the drivers managing their own IOMMU mappings also need a
clearer supported path here. Simply switching from physical addresses
to DMA addresses is not generally sufficient, since the latter belong
to the attachment device's address space.

I also have a draft warning-only mode for DMABUF_DEBUG that I can post
as an RFC. It preserves the CPU fields and logs suspect accesses
instead of deliberately breaking importers. Coverage is incomplete
and the underlying bugs still need fixing; strict mode would remain
available.

Thanks,
Karl