linux-kernel - Re: [PATCH 2/2] drm/nouveau: Don't signal when killing the fence context

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: <f912b8c4-c37b-4c7c-ab9f-e1b44f6fcc13@amd.com>
Date: Thu, 22 May 2025 16:35:42 +0200
From: Christian König <christian.koenig@....com>
To: phasta@...nel.org, Danilo Krummrich <dakr@...nel.org>
Cc: Lyude Paul <lyude@...hat.com>, David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>, Sumit Semwal <sumit.semwal@...aro.org>,
 dri-devel@...ts.freedesktop.org, nouveau@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, linux-media@...r.kernel.org
Subject: Re: [PATCH 2/2] drm/nouveau: Don't signal when killing the fence
 context

On 5/22/25 15:43, Philipp Stanner wrote:
>>
>> Well there is no need to implement it, but when it is implemented the
>> caller *must* call it when polling.
> 
> I don't understand. Please elaborate on that a bit more. If there's no
> need to implement it, then why can't one have a
> __dma_fence_is_signaled(), which is then identical?

Because the caller then doesn't call it when it is implemented.

E.g. you give people a function which ignores the callback.

>>
>> IIRC the background that we didn't allowed this was that we already
>> had the case that users only looked at the signaling bit and then
>> where surprised that it never changed.
> 
> Why would anyone expect that a fence gets signaled by calling a
> function with the name "dma_fence_is_signaled()"? :-)

Because when that function returns true the fence is considered signaled.

> That was my original point, the name is not intuitive at all.
> 
> For example, if a driver doesn't implement that callback but signals
> fences in interrupt handlers, and then forgets to (re-)activate the
> interrupt, fences will never get signaled and callers to
> dma_fence_is_signaled() will never read 'true', which isn't surprising.
> 
> Again, the point remains the same: the driver must guarantee that
> fences will get signaled. Independently from how consumers of the fence
> check it. Consumers could just stop calling dma_fence_is_signaled()
> after the point in time T alltogether and then the driver would still
> have to signal everything.

No it doesn't. You need to call dma_fence_enable_signaling for that.

Regards,
Christian.

> 
> 
> P.
> 
> 
> 
>>
>> Regards,
>> Christian.
>>
>>>
>>>
>>> P.
>>>
>>>>
>>>> Regards,
>>>> Christian.
>>>
>>
>