On Fri, Jun 24, 2016 at 10:19:00AM -0300, Gustavo Padovan wrote: > 2016-06-23 Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>: > > > On Thu, Jun 23, 2016 at 12:29:46PM -0300, Gustavo Padovan wrote: > > > From: Gustavo Padovan <gustavo.padovan@xxxxxxxxxxxxxxx> > > > > > > fence_array requires a function to clean up its state before we > > > are able to call fence_put() and release it. > > > > An explanation along the lines of: > > > > As the array of fence callbacks held by an active struct fence_array > > each has a reference to the struct fence_array, when the owner of the > > fence_array is freed it must dispose of the callback references before > > it can free the fence_array. This can not happen simply during > > fence_release() because of the extra references and so we need a new > > function to run before the final fence_put(). > > > > would help, it is not until you use it in 5/5 that it becomes apparent > > why it is needed. > > That is much better explanation. Thanks! What happens if the owner of the fence_array isn't the last reference holder any more? What if there's a 2nd sync_file that now stops working because the callbacks went poof? Some other driver that registered callbacks? Generally mixing refcounting with explicit teardown is really tricky, fragile and tends to not work. This smells fishy. Why exactly do we have a reference count loop here in the first place that we need to break up using fence_teardown? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
