Re: [RFC PATCH 0/6] dma-buf: Phase out is_signaled() race

[Lucas Stach <l.stach@pengutronix.de>]

Am Donnerstag, dem 29.10.2026 um 11:28 +0100 schrieb Philipp Stanner:
> On Thu, 2026-10-29 at 11:23 +0100, Lucas Stach wrote:
> > Hi Philipp, hi Christian,
> 
> Jo Lucas
> 
> > 
> > Am Donnerstag, dem 29.10.2026 um 10:55 +0100 schrieb Philipp Stanner:
> 
> […]
> 
> > I think we would all be interested in the actual use-case that's
> > sensitive to this kind of latency.
> 
> Me too.
> 
> Let me use this opportunity to stress that in the future, in DRM,
> whenever we have [to accept] a racy "optimization", both commit
> messages and code comments must document why it exists and who
> requested it with what proof.
> 
I don't fully agree that this is a racy optimization. To me it seems
the most critical issue here is that "fence is signaled" is under
specified.

Does it purely mean that the actual hardware operation that the fence
is guarding is done? In that case the current implementation is fine,
as the bit is only set after the HW told us that it is done. This is
the interpretation I would assume was the original intent behind the
current implementation.

Does it mean that the hardware is done and all registered callbacks
have been run, even if the actual work is done in a (indefinitely)
deferred worker? You mentioning explosions caused by the pure signal
state check outside the lock would imply that some consumers of the
fence took the signaled state to mean this interpretation.

> Would save us lots of time when those things are discussed >5 years
> later.
> 
> > 
> > However, I wonder if this is even an issue anymore with the lock
> > inlined into the fence structure.
> 
> Almost no one uses inline-lock so far. So unfortunately, we might
> regress old drivers, maybe.
> 
> But sounds as if you're in favor of phasing the locklessness out :)
> 
I'm in favor of ripping out hard to reason optimizations if they turn
out to not provide any optimization after all. However, before going in
either direction we need to clarify the fence signal state interface. 

Either we keep the (in my interpretation) original intent of the signal
state only telling about HW progress state and thus declare some
current uses as wrong usage of the interface, which need to be fixed.
Or we need to include the SW callbacks too, but then your current lock
approach only guards against code directly executed in the callback
functions. If the implementation of the callback defers anything to a
worker this may still be racy.
And that's also my criticism to this patchset now that I thought a bit
more about this: by simply putting things under the lock you serialized
more of the SW state without actually better defining the guarantees
that this changed fence interface provides or doesn't provide to the
consumers.

Regards,
Lucas