On 9/28/26 12:36, Rob Clark wrote: > On Mon, Sep 28, 2026 at 1:19 AM Christian König > <[email protected]> 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/[email protected]/ >>> Suggested-by: Rob Clark <[email protected]> >>> Cc: Christian König <[email protected]> >>> Cc: Sumit Semwal <[email protected]> >>> Cc: Karl Mehltretter <[email protected]> >>> >>> Signed-off-by: Jianfeng Liu <[email protected]> >>> --- >>> >>> 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 >>> >>
