linux-kernel - Re: [PATCH v4 1/3] drm/shmem-helper: Import dmabuf without mapping its sg

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f77b4c10-768c-49d3-bb19-6f06e19ca603@amd.com>
Date: Fri, 9 May 2025 13:13:37 +0200
From: Christian König <christian.koenig@....com>
To: Thomas Zimmermann <tzimmermann@...e.de>, oushixiong1025@....com
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>, Sean Paul <sean@...rly.run>,
 Jocelyn Falempe <jfalempe@...hat.com>, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, Shixiong Ou <oushixiong@...inos.cn>
Subject: Re: [PATCH v4 1/3] drm/shmem-helper: Import dmabuf without mapping
 its sg_table

On 5/9/25 08:51, Thomas Zimmermann wrote:
>>> +struct drm_gem_object *drm_gem_shmem_prime_import_no_sgt(struct drm_device *dev,
>>> +                             struct dma_buf *dma_buf)
>>
>> Please don't mention "no sgt" in the name, that we use sgtable is an implementation detail.
>>
>> Maybe use something like "no map" or similar.
> 
> To be fair, I asked to not named it something like _vmap(), but rather _no_sgt().  These vmap-only names purely describe a use case. I'd be OK with any name that refers to the difference between the various functions; not just their effect.

Yeah, but "no sgt" is as equally bad as vmap. I don't know a good naming of hand either.

> 
> Unrelated to this series, we might reconsider drm_driver.gem_prime_import_sg_table. If we move the call to dma_buf_map_attachment_unlocked() into the callback and rename it to gem_prime_import_attachment, using sg tables would become optional for all drivers. SHMEM would be able to create the object without SG table without having to reimplement the prime boiler-plate code. Thoughts?

I'm not sure if that would actually be better, but calling dma_buf_map_attachment() should indeed only be done when necessary.

For amdgpu we put that into the TTM TT backend (see function amdgpu_ttm_backend_bind) and I considered switching over radeon and nouveau as well but then just abandoned the plan as to much work.

Regards,
Christian.