From: Jianfeng Liu <liujianfeng1994@gmail.com>
To: dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: linux-arm-msm@vger.kernel.org,
"Jessica Zhang" <jesszhan0024@gmail.com>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
linaro-mm-sig@lists.linaro.org,
"Christian König" <christian.koenig@amd.com>,
"Rob Clark" <robin.clark@oss.qualcomm.com>,
"Sean Paul" <sean@poorly.run>, "Simona Vetter" <simona@ffwll.ch>,
freedreno@lists.freedesktop.org,
"Marijn Suijten" <marijn.suijten@somainline.org>,
"David Airlie" <airlied@gmail.com>,
"Dmitry Baryshkov" <lumag@kernel.org>,
"Abhinav Kumar" <abhinav.kumar@linux.dev>,
"Jianfeng Liu" <liujianfeng1994@gmail.com>,
"Karl Mehltretter" <kmehltretter@gmail.com>
Subject: [RFC PATCH v1 1/2] dma-buf: keep DMABUF_DEBUG off by default
Date: Wed, 23 Sep 2026 15:42:22 +0800 [thread overview]
Message-ID: <20260923074256.9357-2-liujianfeng1994@gmail.com> (raw)
In-Reply-To: <20260923074256.9357-1-liujianfeng1994@gmail.com>
Commit 143755bdabaa9 ("dma-buf: Make DMABUF_DEBUG default to y on
DEBUG_KERNEL kernels") fixed a dangling reference in the DMABUF_DEBUG
default, which had the side effect of enabling the option (and with it
the page-stripping sg_table wrapper handed to importers) on every
kernel with DEBUG_KERNEL=y - i.e. virtually every distro kernel.
drm/msm is broken by this: it maps imported dma-bufs into the GPU's
own pagetables with iommu_map_sgtable(), which needs the struct page
of the attachment sg_table, and it fills the GEM object's page array
through drm_prime_sg_to_page_array(). With the debug wrapper in
place both silently produce garbage (the wrapper zeroes sg->length,
so the page iterator yields nothing and an uninitialized array is
kept). The VM_BIND map job then fails asynchronously after userspace
has already enqueued GPU work referencing the mapping, which shows up
as an arm-smmu translation fault from UCHE, e.g.:
gpu fault: ttbr0=000000088a889000 iova=000000010741c000 dir=READ
type=TRANSLATION source=UCHE
This breaks hardware video decode (clapper, chromium) on Adreno
systems; bisected on a Snapdragon laptop as v7.3-rc3 good,
v7.3-rc4 bad, culprit 143755bdabaa9.
Revert the default until importers that legitimately need to build
phys-based mappings have been converted.
Fixes: 143755bdabaa9 ("dma-buf: Make DMABUF_DEBUG default to y on DEBUG_KERNEL kernels")
Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com>
---
drivers/dma-buf/Kconfig | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index e4f078a326a41..b3c581ef4c987 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -43,7 +43,14 @@ config UDMABUF
config DMABUF_DEBUG
bool "DMA-BUF debug checks"
depends on DMA_SHARED_BUFFER
- default y if DEBUG_KERNEL
+ # NOTE: keep this default n. The page-stripping sg_table wrapper that
+ # this option installs for importers breaks drivers that build a
+ # second-stage IOMMU mapping (phys -> iova) from the attachment sg_table
+ # and therefore still need the struct page, e.g. drm/msm with its
+ # per-process GPU pagetables. Until those importers are fixed, making
+ # this default y breaks hardware video decode and GPU workloads out of
+ # the box on affected systems.
+ default n
help
This option enables additional checks for DMA-BUF importers and
exporters. Specifically it validates that importers do not peek at the
--
2.47.3
next prev parent reply other threads:[~2026-09-23 7:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 7:42 [RFC PATCH v1 0/2] Fix the v7.3-rc4 DMABUF_DEBUG regression breaking drm/msm hardware video decode Jianfeng Liu
2026-09-23 7:42 ` Jianfeng Liu [this message]
2026-09-23 8:03 ` [RFC PATCH v1 1/2] dma-buf: keep DMABUF_DEBUG off by default Christian König
2026-09-24 14:01 ` Rob Clark
2026-09-24 14:54 ` Jianfeng Liu
2026-09-24 15:23 ` Rob Clark
2026-09-25 17:18 ` Rob Clark
2026-09-24 10:28 ` Bryan O'Donoghue
2026-09-23 7:42 ` [RFC PATCH v1 2/2] drm/msm: reject dma-buf imports without struct page info Jianfeng Liu
2026-09-24 10:36 ` Bryan O'Donoghue
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260923074256.9357-2-liujianfeng1994@gmail.com \
--to=liujianfeng1994@gmail.com \
--cc=abhinav.kumar@linux.dev \
--cc=airlied@gmail.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=jesszhan0024@gmail.com \
--cc=kmehltretter@gmail.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=lumag@kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=robin.clark@oss.qualcomm.com \
--cc=sean@poorly.run \
--cc=simona@ffwll.ch \
--cc=sumit.semwal@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.