Le jeudi 29 octobre 2026 à 14:49 +0100, Philipp Stanner a écrit : > Hi, > > On Thu, 2026-10-29 at 14:19 +0100, Paul Cercueil wrote: > > Hi Philipp, > > > > For context, this .release() callback was added to avoid the implicit free > > of > > the base class, which IIRC was a request I got during the review process of > > this > > change set. > > Can't say anything about the request you got, but fences are reference- > counted and the ability to free itself exists since at least > 3c3b177a9369 (2014).
Yes, it already existed when I wrote the code and I was requested to make it explicit. Not trying to make a point here, just stating the reasons why it was written that way. > From dma_fence's perspective it's certainly the desired canonical > pattern since the release() ops prevents fences from the important > feature of decoupling fence producer and consumer. ACK. > > I'm personally fine with the change, but do we need a "keep this field at > > the > > top" comment for the base class in the ffs_dma_fence struct? Or what's the > > policy here? > > When I got into the kernel I was told that it's common practice to > always have the base class as the first element. That also allows for > obtaining the parent class by a mere pointer-cast instead of > container_of. > > But the reality is also that some users are not aware of this rule. I > can document it in a v2 if you like. Let's wait on feedback from more people. I don't have a strong opinion either way. Cheers, -Paul
