All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: linaro-mm-sig@lists.linaro.org, dri-devel@lists.freedesktop.org,
	linux-media@vger.kernel.org, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 05/26] dma-buf: use new iterator in dma_resv_wait_timeout
Date: Mon, 20 Sep 2021 09:27:55 +0200	[thread overview]
Message-ID: <143f7ba9-2629-cb1a-ba66-2d6e50bfc722@gmail.com> (raw)
In-Reply-To: <YUSpiHK7Dd1pF/Mq@phenom.ffwll.local>

Am 17.09.21 um 16:43 schrieb Daniel Vetter:
> On Fri, Sep 17, 2021 at 02:34:52PM +0200, Christian König wrote:
>> This makes the function much simpler since the complex
>> retry logic is now handled elsewhere.
>>
>> Signed-off-by: Christian König <christian.koenig@amd.com>
>> ---
>>   drivers/dma-buf/dma-resv.c | 68 ++++++--------------------------------
>>   1 file changed, 10 insertions(+), 58 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
>> index 9b90bd9ac018..c7db553ab115 100644
>> --- a/drivers/dma-buf/dma-resv.c
>> +++ b/drivers/dma-buf/dma-resv.c
>> @@ -569,74 +569,26 @@ long dma_resv_wait_timeout(struct dma_resv *obj, bool wait_all, bool intr,
>>   			   unsigned long timeout)
>>   {
>>   	long ret = timeout ? timeout : 1;
>> -	unsigned int seq, shared_count;
>> +	struct dma_resv_iter cursor;
>>   	struct dma_fence *fence;
>> -	int i;
>>   
>> -retry:
>> -	shared_count = 0;
>> -	seq = read_seqcount_begin(&obj->seq);
>>   	rcu_read_lock();
> I missed this in my previous conversion reviews, but pls move the
> rcu_read_lock into the iterator. That should simplify the flow in all of
> these quite a bit more, and since the iter_next_unlocked grabs a full
> reference for the iteration body we really don't need that protected by
> rcu.

I intentionally didn't do that because it makes it much more clear that 
we are using RCU here and there is absolutely no guarantee that the 
collection won't change.

But I'm fine if we go down that route instead if you think that's the 
way to go.

Thanks,
Christian.

>
> We can't toss rcu protection for dma_resv anytime soon (if ever), but we
> can at least make it an implementation detail.
>
>> -	i = -1;
>> -
>> -	fence = dma_resv_excl_fence(obj);
>> -	if (fence && !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
>> -		if (!dma_fence_get_rcu(fence))
>> -			goto unlock_retry;
>> +	dma_resv_iter_begin(&cursor, obj, wait_all);
>> +	dma_resv_for_each_fence_unlocked(&cursor, fence) {
>> +		rcu_read_unlock();
>>   
>> -		if (dma_fence_is_signaled(fence)) {
>> -			dma_fence_put(fence);
>> -			fence = NULL;
>> +		ret = dma_fence_wait_timeout(fence, intr, ret);
>> +		if (ret <= 0) {
>> +			dma_resv_iter_end(&cursor);
>> +			return ret;
>>   		}
>>   
>> -	} else {
>> -		fence = NULL;
>> -	}
>> -
>> -	if (wait_all) {
>> -		struct dma_resv_list *fobj = dma_resv_shared_list(obj);
>> -
>> -		if (fobj)
>> -			shared_count = fobj->shared_count;
>> -
>> -		for (i = 0; !fence && i < shared_count; ++i) {
>> -			struct dma_fence *lfence;
>> -
>> -			lfence = rcu_dereference(fobj->shared[i]);
>> -			if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
>> -				     &lfence->flags))
>> -				continue;
>> -
>> -			if (!dma_fence_get_rcu(lfence))
>> -				goto unlock_retry;
>> -
>> -			if (dma_fence_is_signaled(lfence)) {
>> -				dma_fence_put(lfence);
>> -				continue;
>> -			}
>> -
>> -			fence = lfence;
>> -			break;
>> -		}
>> +		rcu_read_lock();
>>   	}
>> -
>> +	dma_resv_iter_end(&cursor);
>>   	rcu_read_unlock();
>> -	if (fence) {
>> -		if (read_seqcount_retry(&obj->seq, seq)) {
>> -			dma_fence_put(fence);
>> -			goto retry;
>> -		}
>>   
>> -		ret = dma_fence_wait_timeout(fence, intr, ret);
>> -		dma_fence_put(fence);
>> -		if (ret > 0 && wait_all && (i + 1 < shared_count))
>> -			goto retry;
>> -	}
>>   	return ret;
>> -
>> -unlock_retry:
>> -	rcu_read_unlock();
>> -	goto retry;
> I think we still have the same semantics, and it's so much tidier.
>
> With the rcu_read_unlock stuff into iterators (also applies to previous
> two patches):
>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
>>   }
>>   EXPORT_SYMBOL_GPL(dma_resv_wait_timeout);
>>   
>> -- 
>> 2.25.1
>>


WARNING: multiple messages have this Message-ID
From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: linaro-mm-sig@lists.linaro.org, dri-devel@lists.freedesktop.org,
	linux-media@vger.kernel.org, intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 05/26] dma-buf: use new iterator in dma_resv_wait_timeout
Date: Mon, 20 Sep 2021 09:27:55 +0200	[thread overview]
Message-ID: <143f7ba9-2629-cb1a-ba66-2d6e50bfc722@gmail.com> (raw)
In-Reply-To: <YUSpiHK7Dd1pF/Mq@phenom.ffwll.local>

Am 17.09.21 um 16:43 schrieb Daniel Vetter:
> On Fri, Sep 17, 2021 at 02:34:52PM +0200, Christian König wrote:
>> This makes the function much simpler since the complex
>> retry logic is now handled elsewhere.
>>
>> Signed-off-by: Christian König <christian.koenig@amd.com>
>> ---
>>   drivers/dma-buf/dma-resv.c | 68 ++++++--------------------------------
>>   1 file changed, 10 insertions(+), 58 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
>> index 9b90bd9ac018..c7db553ab115 100644
>> --- a/drivers/dma-buf/dma-resv.c
>> +++ b/drivers/dma-buf/dma-resv.c
>> @@ -569,74 +569,26 @@ long dma_resv_wait_timeout(struct dma_resv *obj, bool wait_all, bool intr,
>>   			   unsigned long timeout)
>>   {
>>   	long ret = timeout ? timeout : 1;
>> -	unsigned int seq, shared_count;
>> +	struct dma_resv_iter cursor;
>>   	struct dma_fence *fence;
>> -	int i;
>>   
>> -retry:
>> -	shared_count = 0;
>> -	seq = read_seqcount_begin(&obj->seq);
>>   	rcu_read_lock();
> I missed this in my previous conversion reviews, but pls move the
> rcu_read_lock into the iterator. That should simplify the flow in all of
> these quite a bit more, and since the iter_next_unlocked grabs a full
> reference for the iteration body we really don't need that protected by
> rcu.

I intentionally didn't do that because it makes it much more clear that 
we are using RCU here and there is absolutely no guarantee that the 
collection won't change.

But I'm fine if we go down that route instead if you think that's the 
way to go.

Thanks,
Christian.

>
> We can't toss rcu protection for dma_resv anytime soon (if ever), but we
> can at least make it an implementation detail.
>
>> -	i = -1;
>> -
>> -	fence = dma_resv_excl_fence(obj);
>> -	if (fence && !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
>> -		if (!dma_fence_get_rcu(fence))
>> -			goto unlock_retry;
>> +	dma_resv_iter_begin(&cursor, obj, wait_all);
>> +	dma_resv_for_each_fence_unlocked(&cursor, fence) {
>> +		rcu_read_unlock();
>>   
>> -		if (dma_fence_is_signaled(fence)) {
>> -			dma_fence_put(fence);
>> -			fence = NULL;
>> +		ret = dma_fence_wait_timeout(fence, intr, ret);
>> +		if (ret <= 0) {
>> +			dma_resv_iter_end(&cursor);
>> +			return ret;
>>   		}
>>   
>> -	} else {
>> -		fence = NULL;
>> -	}
>> -
>> -	if (wait_all) {
>> -		struct dma_resv_list *fobj = dma_resv_shared_list(obj);
>> -
>> -		if (fobj)
>> -			shared_count = fobj->shared_count;
>> -
>> -		for (i = 0; !fence && i < shared_count; ++i) {
>> -			struct dma_fence *lfence;
>> -
>> -			lfence = rcu_dereference(fobj->shared[i]);
>> -			if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
>> -				     &lfence->flags))
>> -				continue;
>> -
>> -			if (!dma_fence_get_rcu(lfence))
>> -				goto unlock_retry;
>> -
>> -			if (dma_fence_is_signaled(lfence)) {
>> -				dma_fence_put(lfence);
>> -				continue;
>> -			}
>> -
>> -			fence = lfence;
>> -			break;
>> -		}
>> +		rcu_read_lock();
>>   	}
>> -
>> +	dma_resv_iter_end(&cursor);
>>   	rcu_read_unlock();
>> -	if (fence) {
>> -		if (read_seqcount_retry(&obj->seq, seq)) {
>> -			dma_fence_put(fence);
>> -			goto retry;
>> -		}
>>   
>> -		ret = dma_fence_wait_timeout(fence, intr, ret);
>> -		dma_fence_put(fence);
>> -		if (ret > 0 && wait_all && (i + 1 < shared_count))
>> -			goto retry;
>> -	}
>>   	return ret;
>> -
>> -unlock_retry:
>> -	rcu_read_unlock();
>> -	goto retry;
> I think we still have the same semantics, and it's so much tidier.
>
> With the rcu_read_unlock stuff into iterators (also applies to previous
> two patches):
>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
>>   }
>>   EXPORT_SYMBOL_GPL(dma_resv_wait_timeout);
>>   
>> -- 
>> 2.25.1
>>


  reply	other threads:[~2021-09-20  7:28 UTC|newest]

Thread overview: 118+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-17 12:34 Deploying new iterator interface for dma-buf Christian König
2021-09-17 12:34 ` [Intel-gfx] " Christian König
2021-09-17 12:34 ` [PATCH 01/26] dma-buf: add dma_resv_for_each_fence_unlocked v2 Christian König
2021-09-17 12:34   ` [Intel-gfx] " Christian König
2021-09-17 13:23   ` Daniel Vetter
2021-09-17 13:23     ` [Intel-gfx] " Daniel Vetter
2021-09-20  8:43     ` Tvrtko Ursulin
2021-09-20 10:09       ` Christian König
2021-09-20 10:26         ` Tvrtko Ursulin
2021-09-17 12:34 ` [PATCH 02/26] dma-buf: add dma_resv_for_each_fence Christian König
2021-09-17 12:34   ` [Intel-gfx] " Christian König
2021-09-17 13:27   ` Daniel Vetter
2021-09-17 13:27     ` [Intel-gfx] " Daniel Vetter
2021-09-17 14:30     ` Daniel Vetter
2021-09-17 14:30       ` Daniel Vetter
2021-09-17 12:34 ` [PATCH 03/26] dma-buf: use new iterator in dma_resv_copy_fences Christian König
2021-09-17 12:34   ` [Intel-gfx] " Christian König
2021-09-17 14:35   ` Daniel Vetter
2021-09-17 14:35     ` [Intel-gfx] " Daniel Vetter
2021-09-20  7:23     ` Christian König
2021-09-20  7:23       ` [Intel-gfx] " Christian König
2021-09-17 12:34 ` [PATCH 04/26] dma-buf: use new iterator in dma_resv_get_fences v2 Christian König
2021-09-17 12:34   ` [Intel-gfx] " Christian König
2021-09-17 14:39   ` Daniel Vetter
2021-09-17 14:39     ` [Intel-gfx] " Daniel Vetter
2021-09-17 12:34 ` [PATCH 05/26] dma-buf: use new iterator in dma_resv_wait_timeout Christian König
2021-09-17 12:34   ` [Intel-gfx] " Christian König
2021-09-17 14:43   ` Daniel Vetter
2021-09-17 14:43     ` [Intel-gfx] " Daniel Vetter
2021-09-20  7:27     ` Christian König [this message]
2021-09-20  7:27       ` Christian König
2021-09-17 12:34 ` [PATCH 06/26] dma-buf: use new iterator in dma_resv_test_signaled Christian König
2021-09-17 12:34   ` [Intel-gfx] " Christian König
2021-09-17 14:45   ` Daniel Vetter
2021-09-17 14:45     ` [Intel-gfx] " Daniel Vetter
2021-09-17 12:34 ` [PATCH 07/26] drm/ttm: use the new iterator in ttm_bo_flush_all_fences Christian König
2021-09-17 12:34   ` [Intel-gfx] " Christian König
2021-09-17 14:50   ` Daniel Vetter
2021-09-17 14:50     ` [Intel-gfx] " Daniel Vetter
2021-09-17 12:34 ` [PATCH 08/26] drm/amdgpu: use the new iterator in amdgpu_sync_resv Christian König
2021-09-17 12:34   ` [Intel-gfx] " Christian König
2021-09-17 12:34 ` [PATCH 09/26] drm/amdgpu: use new iterator in amdgpu_ttm_bo_eviction_valuable Christian König
2021-09-17 12:34   ` [Intel-gfx] " Christian König
2021-09-17 12:34 ` [PATCH 10/26] drm/msm: use new iterator in msm_gem_describe Christian König
2021-09-17 12:34   ` [Intel-gfx] " Christian König
2021-09-17 12:34 ` [PATCH 11/26] drm/radeon: use new iterator in radeon_sync_resv Christian König
2021-09-17 12:34   ` [Intel-gfx] " Christian König
2021-09-17 12:34 ` [PATCH 12/26] drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2 Christian König
2021-09-17 12:34   ` [Intel-gfx] " Christian König
2021-09-17 14:52   ` Daniel Vetter
2021-09-17 14:52     ` [Intel-gfx] " Daniel Vetter
2021-11-15 14:03   ` Sascha Hauer
2021-11-15 14:03     ` Sascha Hauer
2021-11-15 14:03     ` [Intel-gfx] " Sascha Hauer
2021-11-15 14:08     ` Daniel Vetter
2021-11-15 14:08       ` [Intel-gfx] " Daniel Vetter
2021-11-15 14:08       ` Daniel Vetter
2021-11-15 20:32       ` Christian König
2021-11-15 20:32         ` Christian König
2021-11-15 20:32         ` [Intel-gfx] " Christian König
2021-11-16  7:56       ` Sascha Hauer
2021-11-16  7:56         ` [Intel-gfx] " Sascha Hauer
2021-11-16  7:56         ` Sascha Hauer
2021-09-17 12:35 ` [PATCH 13/26] drm/i915: use the new iterator in i915_gem_busy_ioctl Christian König
2021-09-17 12:35   ` [Intel-gfx] " Christian König
2021-09-20  8:45   ` Tvrtko Ursulin
2021-09-20 10:13     ` Christian König
2021-09-20 10:33       ` Tvrtko Ursulin
2021-09-21  9:41         ` Christian König
2021-09-21 13:10           ` Tvrtko Ursulin
2021-09-17 12:35 ` [PATCH 14/26] drm/i915: use the new iterator in i915_sw_fence_await_reservation v3 Christian König
2021-09-17 12:35   ` [Intel-gfx] " Christian König
2021-09-20  8:45   ` Tvrtko Ursulin
2021-09-20  8:47     ` Tvrtko Ursulin
2021-09-20 10:14       ` Christian König
2021-09-17 12:35 ` [PATCH 15/26] drm/i915: use the new iterator in i915_request_await_object v2 Christian König
2021-09-17 12:35   ` [Intel-gfx] " Christian König
2021-09-17 12:35 ` [PATCH 16/26] drm/i915: use new iterator in i915_gem_object_wait_reservation v2 Christian König
2021-09-17 12:35   ` [Intel-gfx] " Christian König
2021-09-20 10:00   ` Tvrtko Ursulin
2021-09-21 17:35     ` Christian König
2021-09-17 12:35 ` [PATCH 17/26] drm/i915: use new iterator in i915_gem_object_wait_priority v2 Christian König
2021-09-17 12:35   ` [Intel-gfx] " Christian König
2021-09-17 12:35 ` [PATCH 18/26] drm/i915: use new iterator in i915_gem_object_last_write_engine v2 Christian König
2021-09-17 12:35   ` [Intel-gfx] " Christian König
2021-09-17 12:35 ` [PATCH 19/26] drm/i915: use new cursor in intel_prepare_plane_fb v2 Christian König
2021-09-17 12:35   ` [Intel-gfx] " Christian König
2021-09-17 12:35 ` [PATCH 20/26] drm: use new iterator in drm_gem_fence_array_add_implicit v2 Christian König
2021-09-17 12:35   ` [Intel-gfx] " Christian König
2021-09-17 14:53   ` Daniel Vetter
2021-09-17 14:53     ` [Intel-gfx] " Daniel Vetter
2021-09-20  7:31     ` Christian König
2021-09-20  7:31       ` [Intel-gfx] " Christian König
2021-09-17 12:35 ` [PATCH 21/26] drm: use new iterator in drm_gem_plane_helper_prepare_fb v2 Christian König
2021-09-17 12:35   ` [Intel-gfx] " Christian König
2021-09-17 14:55   ` Daniel Vetter
2021-09-17 14:55     ` [Intel-gfx] " Daniel Vetter
2021-09-20  7:35     ` Christian König
2021-09-20  7:35       ` [Intel-gfx] " Christian König
2021-09-17 12:35 ` [PATCH 22/26] drm/nouveau: use the new iterator in nouveau_fence_sync Christian König
2021-09-17 12:35   ` [Intel-gfx] " Christian König
2021-09-17 12:35 ` [PATCH 23/26] drm/nouveau: use the new interator in nv50_wndw_prepare_fb v2 Christian König
2021-09-17 12:35   ` [Intel-gfx] " Christian König
2021-09-17 12:35 ` [PATCH 24/26] drm/etnaviv: use new iterator in etnaviv_gem_describe Christian König
2021-09-17 12:35   ` [Intel-gfx] " Christian König
2021-09-17 12:35 ` [PATCH 25/26] drm/etnaviv: replace dma_resv_get_excl_unlocked Christian König
2021-09-17 12:35   ` [Intel-gfx] " Christian König
2021-09-17 12:35 ` [PATCH 26/26] dma-buf: nuke dma_resv_get_excl_unlocked Christian König
2021-09-17 12:35   ` [Intel-gfx] " Christian König
2021-09-17 14:56   ` Daniel Vetter
2021-09-17 14:56     ` [Intel-gfx] " Daniel Vetter
2021-09-17 14:01 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/26] dma-buf: add dma_resv_for_each_fence_unlocked v2 Patchwork
2021-09-17 14:29 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-09-17 15:43 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2021-09-22  9:10 Deploying new iterator interface for dma-buf Christian König
2021-09-22  9:10 ` [PATCH 05/26] dma-buf: use new iterator in dma_resv_wait_timeout Christian König
2021-09-21 17:36 [PATCH 01/26] dma-buf: add dma_resv_for_each_fence_unlocked v3 Christian König
2021-09-21 17:36 ` [PATCH 05/26] dma-buf: use new iterator in dma_resv_wait_timeout Christian König
2021-09-16 11:30 Deploying new iterator interface for dma-buf Christian König
2021-09-16 11:30 ` [PATCH 05/26] dma-buf: use new iterator in dma_resv_wait_timeout Christian König
2021-09-13 13:16 Deploying new iterator interface for dma-buf Christian König
2021-09-13 13:16 ` [PATCH 05/26] dma-buf: use new iterator in dma_resv_wait_timeout Christian König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=143f7ba9-2629-cb1a-ba66-2d6e50bfc722@gmail.com \
    --to=ckoenig.leichtzumerken@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-media@vger.kernel.org \
    --subject='Re: [PATCH 05/26] dma-buf: use new iterator in dma_resv_wait_timeout' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.