linux-kernel - Re: [PATCH 0/6] dma-fence: Remove return code of dma_fence

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <48352d7e-5e43-4683-9f00-b77ae571d8f6@amd.com>
Date: Wed, 26 Nov 2025 15:02:15 +0100
From: Christian König <christian.koenig@....com>
To: Philipp Stanner <phasta@...nel.org>,
 Sumit Semwal <sumit.semwal@...aro.org>, Gustavo Padovan
 <gustavo@...ovan.org>, Felix Kuehling <Felix.Kuehling@....com>,
 Alex Deucher <alexander.deucher@....com>, David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>, Jani Nikula <jani.nikula@...ux.intel.com>,
 Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@...el.com>, Tvrtko Ursulin
 <tursulin@...ulin.net>, Huang Rui <ray.huang@....com>,
 Matthew Auld <matthew.auld@...el.com>,
 Matthew Brost <matthew.brost@...el.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 Lucas De Marchi <lucas.demarchi@...el.com>,
 Thomas Hellström <thomas.hellstrom@...ux.intel.com>
Cc: linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 linaro-mm-sig@...ts.linaro.org, linux-kernel@...r.kernel.org,
 amd-gfx@...ts.freedesktop.org, intel-gfx@...ts.freedesktop.org,
 intel-xe@...ts.freedesktop.org, rust-for-linux@...r.kernel.org
Subject: Re: [PATCH 0/6] dma-fence: Remove return code of dma_fence_signal()
 et al.

On 11/26/25 14:19, Philipp Stanner wrote:
> Barely anyone uses dma_fence_signal()'s (and similar functions') return
> code. Checking it is pretty much useless anyways, because what are you
> going to do if a fence was already signal it? Unsignal it and signal it
> again? ;p

Reviewed-by: Christian König <christian.koenig@....com> for the entire series.

Please push to drm-misc-next or leave me a note when I should pick it up.

> Removing the return code simplifies the API and makes it easier for me
> to sit on top with Rust DmaFence.

BTW, I have an rb for embedding the lock and I'm now writing test cases.

When that is done you should be able to base the Rust DmaFence abstraction on that as well.

Regards,
Christian.

> 
> Philipp Stanner (6):
>   dma-buf/dma-fence: Add dma_fence_test_signaled_flag()
>   amd/amdkfd: Ignore return code of dma_fence_signal()
>   drm/gpu/xe: Ignore dma_fenc_signal() return code
>   dma-buf: Don't misuse dma_fence_signal()
>   drm/ttm: Remove return check of dma_fence_signal()
>   dma-buf/dma-fence: Remove return code of signaling-functions
> 
>  drivers/dma-buf/dma-fence.c                   | 59 ++++++-------------
>  drivers/dma-buf/st-dma-fence.c                |  7 +--
>  drivers/gpu/drm/amd/amdkfd/kfd_process.c      |  5 +-
>  .../gpu/drm/ttm/tests/ttm_bo_validate_test.c  |  3 +-
>  drivers/gpu/drm/xe/xe_hw_fence.c              |  5 +-
>  include/linux/dma-fence.h                     | 33 ++++++++---
>  6 files changed, 53 insertions(+), 59 deletions(-)
>