linux-kernel - Re: [RFC PATCH 2/4] rust: sync: Add dma

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: <c1d4ad2a-44a0-4c04-b0b4-94d6242d4ae8@amd.com>
Date: Tue, 10 Feb 2026 15:06:38 +0100
From: Christian König <christian.koenig@....com>
To: phasta@...nel.org, Alice Ryhl <aliceryhl@...gle.com>,
 Boris Brezillon <boris.brezillon@...labora.com>
Cc: Danilo Krummrich <dakr@...nel.org>, David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>, Gary Guo <gary@...yguo.net>,
 Benno Lossin <lossin@...nel.org>,
 Daniel Almeida <daniel.almeida@...labora.com>,
 Joel Fernandes <joelagnelf@...dia.com>, linux-kernel@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, rust-for-linux@...r.kernel.org
Subject: Re: [RFC PATCH 2/4] rust: sync: Add dma_fence abstractions

On 2/10/26 15:00, Philipp Stanner wrote:
> On Tue, 2026-02-10 at 14:56 +0100, Christian König wrote:
>> On 2/10/26 14:49, Alice Ryhl wrote:
>>> On Tue, Feb 10, 2026 at 02:26:31PM +0100, Boris Brezillon wrote:
>>>> On Tue, 10 Feb 2026 13:15:31 +0000
>>>> Alice Ryhl <aliceryhl@...gle.com> wrote:
>>>>
>>>>
>>>>
> 
> […]
> 
>>>> I mean, the timeout handler should also be considered a DMA-signalling
>>>> path, and the same rules should apply to it.
>>>
>>> I guess that's fair. Even with a timeout you want both to be signalling
>>> path.
>>>
>>> I guess more generally, if a fence is signalled by mechanism A or B,
>>> whichever happens first, you have the choice between:
>>
>> That doesn't happen in practice.
>>
>> For each fence you only have one signaling path you need to guarantee forward progress for.
>>
>> All other signaling paths are just opportunistically optimizations which *can* signal the fence, but there is no guarantee that they will.
> 
> Are you now referring to the fast-path callbacks like fence->ops-
>> is_signaled()? Or are you talking about different reference holders
> which might want to signal?

Yes, I'm referring to the is_signaled() callback.

When you have multiple reference holders which can all signal the fence by calling dma_fence_signal then there is clearly something going wrong.

What can be is that you have something like a fallback timer for buddy HW which swallows IRQs (e.g. like radeon or amdgpu have), but then you have something like a high level spinlock which makes sure that your IRQ handler is neither re-entrant nor multiple instances running at the same time on different CPUs.

>>
>> We used to have some exceptions to that, especially around aborting submissions, but those turned out to be a really bad idea as well.  
>>
>> Thinking more about it you should probably enforce that there is only one signaling path for each fence signaling.
> 
> An idea that is floating around is to move the entire fence signaling
> functionality into the dma fence context. That would have exclusive
> access, and could also finally guarantee that fences must be signaled
> in order.

That sounds like a sane idea to me.

Regards,
Christian.

> 
> 
> P.