| Message ID | 1466695790-2833-2-git-send-email-gustavo@padovan.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Jun 23, 2016 at 12:29:46PM -0300, Gustavo Padovan wrote: > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > > 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. -Chris
2016-06-23 Chris Wilson <chris@chris-wilson.co.uk>: > On Thu, Jun 23, 2016 at 12:29:46PM -0300, Gustavo Padovan wrote: > > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > > > > 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! Gustavo
On Fri, Jun 24, 2016 at 10:19:00AM -0300, Gustavo Padovan wrote: > 2016-06-23 Chris Wilson <chris@chris-wilson.co.uk>: > > > On Thu, Jun 23, 2016 at 12:29:46PM -0300, Gustavo Padovan wrote: > > > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> > > > > > > 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
diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c index 4d51f9e..4e61afb 100644 --- a/drivers/dma-buf/fence.c +++ b/drivers/dma-buf/fence.c @@ -185,6 +185,13 @@ void fence_release(struct kref *kref) } EXPORT_SYMBOL(fence_release); +void fence_teardown(struct fence *fence) +{ + if (fence->ops->teardown) + fence->ops->teardown(fence); +} +EXPORT_SYMBOL(fence_teardown); + void fence_free(struct fence *fence) { kfree_rcu(fence, rcu); diff --git a/include/linux/fence.h b/include/linux/fence.h index 44d945e..1d3b671 100644 --- a/include/linux/fence.h +++ b/include/linux/fence.h @@ -114,6 +114,7 @@ struct fence_cb { * @enable_signaling: enable software signaling of fence. * @signaled: [optional] peek whether the fence is signaled, can be null. * @wait: custom wait implementation, or fence_default_wait. + * @teardown: [optional] teardown fence data but not put it * @release: [optional] called on destruction of fence, can be null * @fill_driver_data: [optional] callback to fill in free-form debug info * Returns amount of bytes filled, or -errno. @@ -161,6 +162,10 @@ struct fence_cb { * which should be treated as if the fence is signaled. For example a hardware * lockup could be reported like that. * + * Notes on teardown: + * Can be NULL, this function clean ups the fence data before the fence_put + * call. + * * Notes on release: * Can be NULL, this function allows additional commands to run on * destruction of the fence. Can be called from irq context. @@ -173,6 +178,7 @@ struct fence_ops { bool (*enable_signaling)(struct fence *fence); bool (*signaled)(struct fence *fence); signed long (*wait)(struct fence *fence, bool intr, signed long timeout); + void (*teardown)(struct fence *fence); void (*release)(struct fence *fence); int (*fill_driver_data)(struct fence *fence, void *data, int size); @@ -184,6 +190,7 @@ void fence_init(struct fence *fence, const struct fence_ops *ops, spinlock_t *lock, u64 context, unsigned seqno); void fence_release(struct kref *kref); +void fence_teardown(struct fence *fence); void fence_free(struct fence *fence); /**