diff options
Diffstat (limited to 'include/linux')
| -rw-r--r-- | include/linux/dma-fence.h | 31 |
1 files changed, 22 insertions, 9 deletions
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h index 10a849cb2d3f..64639e104110 100644 --- a/include/linux/dma-fence.h +++ b/include/linux/dma-fence.h @@ -378,15 +378,28 @@ bool dma_fence_remove_callback(struct dma_fence *fence, struct dma_fence_cb *cb); void dma_fence_enable_sw_signaling(struct dma_fence *fence); -static inline const char *dma_fence_driver_name(struct dma_fence *fence) -{ - return fence->ops->get_driver_name(fence); -} - -static inline const char *dma_fence_timeline_name(struct dma_fence *fence) -{ - return fence->ops->get_timeline_name(fence); -} +/** + * DOC: Safe external access to driver provided object members + * + * All data not stored directly in the dma-fence object, such as the + * &dma_fence.lock and memory potentially accessed by functions in the + * &dma_fence.ops table, MUST NOT be accessed after the fence has been signalled + * because after that point drivers are allowed to free it. + * + * All code accessing that data via the dma-fence API (or directly, which is + * discouraged), MUST make sure to contain the complete access within a + * &rcu_read_lock and &rcu_read_unlock pair. + * + * Some dma-fence API handles this automatically, while other, as for example + * &dma_fence_driver_name and &dma_fence_timeline_name, leave that + * responsibility to the caller. + * + * To enable this scheme to work drivers MUST ensure a RCU grace period elapses + * between signalling the fence and freeing the said data. + * + */ +const char __rcu *dma_fence_driver_name(struct dma_fence *fence); +const char __rcu *dma_fence_timeline_name(struct dma_fence *fence); /** * dma_fence_is_signaled_locked - Return an indication if the fence |