Re: [RFC PATCH 2/3] dma-buf: add a warn-only mode to DMABUF_DEBUG

["Diederik de Haas" <diederik@cknow-tech.com>]

On Fri Oct 9, 2026 at 2:53 PM CEST, Jason Gunthorpe wrote:
> On Wed, Oct 07, 2026 at 02:02:31PM +0200, Diederik de Haas wrote:
>> [ 1091.981354] rc rc3: two consecutive events of type space
>> [ 1104.670513] input: EDIFIER e235 (AVRCP) as /devices/virtual/input/input12
>> [ 1172.090231] devfreq fb000000.gpu: Couldn't update frequency transition information.
>> [ 1189.403278] devfreq fb000000.gpu: Couldn't update frequency transition information.
>> [ 1206.309295] input: EDIFIER e235 (AVRCP) as /devices/virtual/input/input13
>> [ 1268.968696] DMA-BUF: importer used the CPU side of an exporter's sg_table
>
> This is a nice stack trace, is that the point of this series?

Actually only the last line, I just "couldn't help myself" to also include
the "Couldn't update frequency transition information" part.
It can be unrelated. Or not. I lack the knowledge to make that determination.

>> [ 1268.968710] CPU: 6 UID: 1000 PID: 29025 Comm: sway Not tainted 7.3-rc6+unreleased-arm64-cknow #1 PREEMPTLAZY  Debian 7.3~rc6-3
>> [ 1268.968715] Hardware name: FriendlyElec NanoPC-T6 Plus (DT)
>> [ 1268.968717] Call trace:
>> [ 1268.968719]  show_stack+0x20/0x38 (C)
>> [ 1268.968726]  dump_stack_lvl+0x60/0x80
>> [ 1268.968730]  sg_dmabuf_cpu_access_warn.part.0+0x24/0x30
>> [ 1268.968734]  sg_dmabuf_cpu_access_warn+0x34/0x38
>> [ 1268.968739]  iommu_map_sg+0xc8/0x1e0
>> [ 1268.968745]  rockchip_gem_iommu_map+0x8c/0x128 [rockchipdrm]
>> [ 1268.968757]  rockchip_gem_prime_import_sg_table+0x58/0x160 [rockchipdrm]
>> [ 1268.968761]  drm_gem_prime_import_dev+0xa8/0x1d0 [drm]
>> [ 1268.968776]  drm_gem_prime_fd_to_handle+0x1a4/0x280 [drm]

IIUC this was meant to show the actual problem.

> So.. This is the exact same thing I need for iommufd.
>
> rockchip is managing its own iommu domain and you cannot map to an
> iommu domain without using a physical address.
>
> Of course it is *completely* illegal to call iommu_map_sgtable() in the
> importer side of a dmabuf.

I can't say anything useful wrt this, so I added the maintainers of
``drivers/gpu/drm/rockchip/rockchip_drm_gem.c`` to the recipient list.

> static int rockchip_gem_iommu_map(struct rockchip_gem_object *rk_obj)
> {
> [..]
> 	ret = iommu_map_sgtable(private->domain, rk_obj->dma_addr, rk_obj->sgt,
> 				prot);

It may not matter, but I noticed the majority of that function is from 2016:
38f993b7c59e ("drm/rockchip: Do not use DMA mapping API if attached to IOMMU domain")
1aa5ca6e3ec6 ("drm/rockchip: Use common IOMMU API to attach devices")

From the first commit (38f993b7c59e):

    The API is not suitable for subsystems consisting of multiple devices
    and requires severe hacks to use it. To mitigate this, this patch
    implements allocation and address space management locally by using
    helpers provided by DRM framework, like other DRM drivers do, e.g.
    Tegra.
    
    This patch should not introduce any functional changes until the driver
    is made to attach subdevices into an IOMMU domain with the generic IOMMU
    API, which will happen in following patch. Based heavily on GEM
    implementation of Tegra DRM driver.

And I assume "following patch" was 1aa5ca6e3ec6.

Cheers,
  Diederik