Am 22.01.2018 um 21:09 schrieb Chris Wilson:
Quoting Christian König (2018-01-22 20:00:03)We need to set shared_count even if we already have a fence to wait for. v2: init i to -1 as well Signed-off-by: Christian König <christian.koenig@xxxxxxx> Cc: stable@xxxxxxxxxxxxxxx Tested-by: Lyude Paul <lyude@xxxxxxxxxx> Reviewed-by: Lyude Paul <lyude@xxxxxxxxxx> --- drivers/dma-buf/reservation.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c index 461afa9febd4..314eb1071cce 100644 --- a/drivers/dma-buf/reservation.c +++ b/drivers/dma-buf/reservation.c @@ -484,13 +484,15 @@ long reservation_object_wait_timeout_rcu(struct reservation_object *obj, unsigned long timeout) { struct dma_fence *fence; - unsigned seq, shared_count, i = 0; + unsigned seq, shared_count; long ret = timeout ? timeout : 1; + int i;retry:shared_count = 0; seq = read_seqcount_begin(&obj->seq); rcu_read_lock(); + i = -1;Could be before the seqlock, but Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> Are we at the point where just grabbing the snapshot of fences with your new get_fences_rcu() returning a single array will be simpler? (It also has the change in behaviour of not updating the snapshot across the long lived wait.)
Yeah, thought about that as well.
If you want to avoid the kmalloc, we could teach it populate the caller's stack allocated array first.
Something like a helper function which just grabs all fences and puts them in an array of size n? And if the array is to small we return -ENOSPC and the caller needs to resize it.
Good idea, putting this on my TODO list, but no idea when I can get around to actually doing it.
Christian.
-Chris
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
