On Fri, Jul 02, 2021 at 01:16:39PM +0200, Christian König wrote:
Explicitly document that code can't assume that shared fences signal after the exclusive fence.
Signed-off-by: Christian König christian.koenig@amd.com
drivers/dma-buf/dma-resv.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c index f26c71747d43..4ab02b6c387a 100644 --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -235,7 +235,10 @@ EXPORT_SYMBOL(dma_resv_reset_shared_max);
- @fence: the shared fence to add
- Add a fence to a shared slot, obj->lock must be held, and
- dma_resv_reserve_shared() has been called.
- dma_resv_reserve_shared() has been called. The shared fences can signal in
- any order and there is especially no guarantee that shared fences signal
- after the exclusive one. Code relying on any signaling order is broken and
- needs to be fixed.
This feels like the last place I'd go look for how I should handle dependencies. It's the function for adding shared fences after all, has absolutely nothing to do with whether we should wait for them.
I'll type up something else. -Daniel
*/ void dma_resv_add_shared_fence(struct dma_resv *obj, struct dma_fence *fence) { -- 2.25.1