Re: [PATCH 07/20] dma-buf: use inline lock for the dma-fence-array

[Philipp Stanner <phasta@mailbox.org>]

On Wed, 2025-11-12 at 14:53 +0100, Christian König wrote:
> On 11/7/25 13:04, Philipp Stanner wrote:
> > On Fri, 2025-10-31 at 14:16 +0100, Christian König wrote:
> > > Just as proof of concept and minor cleanup.
> > 
> > I maintain that even relatively simple commits should give a new
> > reader
> > ore one who's browsing through the log in 3 years a rough idea
> > what's
> > going on.
> > 
> > That is: quickly describe what the situation (motivation) is and
> > what
> > the commit does.
> > 
> > At the very least "proof of concept" is nothing anyone would expect
> > in
> > a non-RFC patch. To me as a non-expert in dma-buf it's not clear at
> > all
> > whether this patch here is actually necessary, i.e., solves a
> > problem. 
> 
> Proof of concept in the sense "I use this patch to test the concept
> with with the kernel unit tests and robots".

I think since independent fences are the recommendation (see below),
it's better to have this commit being about moving users to the
recommended usage.

> 
> > I also don't see how replacing one lock position with another is a
> > "cleanup". Sharing spinlocks is perfectly legal and will remain so,
> > no?
> 
> Well that's the more interesting question.
> 
> On the one hand I'm now pretty sure that allowing those shared fences
> was a really bad idea, there is simply no valid use case for them.
> 
> On the other hand changing all the existing implementations would be
> tons of work with limited gain. I already tried that before and
> without some intermediate solution like this here it would be an
> enormous patch set touching all current implementations at the same
> time.

I also prefer (want) non-shared fences for Rust.

What we can do is explicitly document that independent fences are the
strong recommendation for new users. "It is recommended that you pass
NULL for the fence so that fences get separate locks, which allows for
cleanly decoupling fences from their issuer and even the fence context
object (being protected by the same spinlock)."

I think that's not included in the series yet.


P.