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: 9+ 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-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®