On 10/29/26 15:18, Paul Cercueil wrote: > 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.
As far as I know It is indeed common practice , if you want a comment or not on your structure that the base class needs to be the first element or the dma_fence release will break is totally up to you I think. On the other hand it is maybe possible to provide a dma_fence_alloc_obj() macro which wraps kmalloc_obj and compile time asserts that the member you give for the base class is at offset 0. Regards, Christian. > > Cheers, > -Paul
