Quoting Tvrtko Ursulin (2019-09-27 13:08:51) > > On 27/09/2019 12:25, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-09-27 12:10:29) > >> > >> On 25/09/2019 11:01, Chris Wilson wrote: > >>> +struct dma_fence * > >>> +__i915_active_fence_set(struct i915_active_fence *active, > >>> + struct dma_fence *fence) > >> > >> Can you add a short comment for this function explaining the racyness > >> and so why it returns prev and what should the callers do with it? > > > > Before using this function, we had the callers declare what mutex guards > > this timeline and we check here that is held. > > No, I mean because it has to reload prev and return it to the caller, > which implies that is to handle some designed-in racy-ness which I think > should be mentioned. But that's not racing with the caller, that just racing with the callback from the interrupt handler and the reason why we have to check after serialising is called out. /* serialise with prev->cb_list */ ? The caller is responsible for ensuring that prev is executed before fence to keep the timeline in the same order as recorded. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
