On Wed, Sep 23, 2026 at 1:03 AM Christian König <[email protected]> wrote: > > On 9/23/26 09:42, Jianfeng Liu wrote: > > [Sie erhalten nicht häufig E-Mails von [email protected]. Weitere > > Informationen, warum dies wichtig ist, finden Sie unter > > https://aka.ms/LearnAboutSenderIdentification ] > > > > 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, > > Interesting point, we should probably change that.
So the assessment of what is going wrong looks pretty wrong.. VM_BIND should never lead to iommu_map_sgtable() (which is never used for gpu per-process pgtables), for example.. but is used for mapping for scanout. And pages are never used for mapping in either path. However there are a few places where sg->length is used (in iommu code and msm).. AFAICT dma_buf_wrap_sg_table() zeroing out sg->length is what the actual problem here is, rather than any use of struct page. (And yeah, I should get rid of use of drm_prime_sg_to_page_array().. but that cleanup that I haven't found time for shouldn't be the problem here.) BR, -R
