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: <4f3f36cb-3af7-4461-9852-9ababcc9b6cf@amd.com>
Date: Tue, 10 Feb 2026 16:50:08 +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 16:32, Philipp Stanner wrote:
> On Tue, 2026-02-10 at 15:06 +0100, Christian König wrote:
>> 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.
> 
> From our previous discussions it always seemed to me that there is
> already something wrong when is_signaled() fastpaths are being
> utilized. Remember the mess we have in Nouveau because of that?

Yeah, but that is Nouveau specific. In other words Nouveau has a problem with that because it doesn't like to have already signaled fences on its pending list but still wants to use the fast path.

> I agree that it sounds very sane to just have 1 party that can signal a
> fence.
> 
> However, that also implies that the fastpath is wrong because
> 
> a) a consumer of a fence can use that to poll on the fence and
> b) because it breaks good naming pattern, where a check whether a fence
> is signaled can result in the fence being signaled.
> 
> So I would kill that fast path for good.

Yeah that is not something we can do, some use cases completely rely on that.

E.g. on mobile devices it is normal to not enable fence interrupts and rely on repeating interrupts or timeouts to signal the fences.

> In the past you mentioned that you had users who were wondering why
> there fences are not signalling (like yeah, if you don't call
> dma_fence_signal(), then your fence will not signal). What ever the
> confusion was, this time we have the chance to set it straight.

Not sure what you mean with that.

Christian.

> 
> P.