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
Subject: Re: [PATCH 04/24] dma-buf: add dma_resv_get_singleton v2
Date: Mon, 3 Jan 2022 12:13:41 +0100	[thread overview]
Message-ID: <95929048-b381-78d1-462c-e7b910c784b0@gmail.com> (raw)
In-Reply-To: <YcOWyHzY22ZCCvef@phenom.ffwll.local>

Am 22.12.21 um 22:21 schrieb Daniel Vetter:
> On Tue, Dec 07, 2021 at 01:33:51PM +0100, Christian König wrote:
>> Add a function to simplify getting a single fence for all the fences in
>> the dma_resv object.
>>
>> v2: fix ref leak in error handling
>>
>> Signed-off-by: Christian König <christian.koenig@amd.com>
>> ---
>>   drivers/dma-buf/dma-resv.c | 52 ++++++++++++++++++++++++++++++++++++++
>>   include/linux/dma-resv.h   |  2 ++
>>   2 files changed, 54 insertions(+)
>>
>> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
>> index 480c305554a1..694716a3d66d 100644
>> --- a/drivers/dma-buf/dma-resv.c
>> +++ b/drivers/dma-buf/dma-resv.c
>> @@ -34,6 +34,7 @@
>>    */
>>   
>>   #include <linux/dma-resv.h>
>> +#include <linux/dma-fence-array.h>
>>   #include <linux/export.h>
>>   #include <linux/mm.h>
>>   #include <linux/sched/mm.h>
>> @@ -657,6 +658,57 @@ int dma_resv_get_fences(struct dma_resv *obj, bool write,
>>   }
>>   EXPORT_SYMBOL_GPL(dma_resv_get_fences);
>>   
>> +/**
>> + * dma_resv_get_singleton - Get a single fence for all the fences
>> + * @obj: the reservation object
>> + * @write: true if we should return all fences
>> + * @fence: the resulting fence
>> + *
>> + * Get a single fence representing all the fences inside the resv object.
>> + * Returns either 0 for success or -ENOMEM.
>> + *
>> + * Warning: This can't be used like this when adding the fence back to the resv
>> + * object since that can lead to stack corruption when finalizing the
>> + * dma_fence_array.
> Uh I don't get this one? I thought the only problem with nested fences is
> the signalling recursion, which we work around with the irq_work?

Nope, the main problem is finalizing the dma_fence_array.

E.g. imagine that you build up a chain of dma_fence_array objects like this:
a<-b<-c<-d<-e<-f.....

With each one referencing the previous dma_fence_array and then you call 
dma_fence_put() on the last one. That in turn will cause calling 
dma_fence_put() on the previous one, which in turn will cause 
dma_fence_put() one the one before the previous one etc....

In other words you recurse because each dma_fence_array instance drops 
the last reference of it's predecessor.

What we could do is to delegate dropping the reference to the containing 
fences in a dma_fence_array as well, but that would require some changes 
to the irq_work_run_list() function to be halve way efficient.

> Also if there's really an issue with dma_fence_array fences, then that
> warning should be on the dma_resv kerneldoc, not somewhere hidden like
> this. And finally I really don't see what can go wrong, sure we'll end up
> with the same fence once in the dma_resv_list and then once more in the
> fence array. But they're all refcounted, so really shouldn't matter.
>
> The code itself looks correct, but me not understanding what even goes
> wrong here freaks me out a bit.

Yeah, IIRC we already discussed that with Jason in length as well.

Essentially what you can't do is to put a dma_fence_array into another 
dma_fence_array without causing issues.

So I think we should maybe just add a WARN_ON() into 
dma_fence_array_init() to make sure that this never happens.

Regards,
Christian.

>
> I guess something to figure out next year, I kinda hoped I could squeeze a
> review in before I disappear :-/
> -Daniel
>
>> + */
>> +int dma_resv_get_singleton(struct dma_resv *obj, bool write,
>> +			   struct dma_fence **fence)
>> +{
>> +	struct dma_fence_array *array;
>> +	struct dma_fence **fences;
>> +	unsigned count;
>> +	int r;
>> +
>> +	r = dma_resv_get_fences(obj, write, &count, &fences);
>> +        if (r)
>> +		return r;
>> +
>> +	if (count == 0) {
>> +		*fence = NULL;
>> +		return 0;
>> +	}
>> +
>> +	if (count == 1) {
>> +		*fence = fences[0];
>> +		kfree(fences);
>> +		return 0;
>> +	}
>> +
>> +	array = dma_fence_array_create(count, fences,
>> +				       dma_fence_context_alloc(1),
>> +				       1, false);
>> +	if (!array) {
>> +		while (count--)
>> +			dma_fence_put(fences[count]);
>> +		kfree(fences);
>> +		return -ENOMEM;
>> +	}
>> +
>> +	*fence = &array->base;
>> +	return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(dma_resv_get_singleton);
>> +
>>   /**
>>    * dma_resv_wait_timeout - Wait on reservation's objects
>>    * shared and/or exclusive fences.
>> diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
>> index fa2002939b19..cdfbbda6f600 100644
>> --- a/include/linux/dma-resv.h
>> +++ b/include/linux/dma-resv.h
>> @@ -438,6 +438,8 @@ void dma_resv_replace_fences(struct dma_resv *obj, uint64_t context,
>>   void dma_resv_add_excl_fence(struct dma_resv *obj, struct dma_fence *fence);
>>   int dma_resv_get_fences(struct dma_resv *obj, bool write,
>>   			unsigned int *num_fences, struct dma_fence ***fences);
>> +int dma_resv_get_singleton(struct dma_resv *obj, bool write,
>> +			   struct dma_fence **fence);
>>   int dma_resv_copy_fences(struct dma_resv *dst, struct dma_resv *src);
>>   long dma_resv_wait_timeout(struct dma_resv *obj, bool wait_all, bool intr,
>>   			   unsigned long timeout);
>> -- 
>> 2.25.1
>>


WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org,
	linaro-mm-sig@lists.linaro.org
Subject: Re: [PATCH 04/24] dma-buf: add dma_resv_get_singleton v2
Date: Mon, 3 Jan 2022 12:13:41 +0100	[thread overview]
Message-ID: <95929048-b381-78d1-462c-e7b910c784b0@gmail.com> (raw)
In-Reply-To: <YcOWyHzY22ZCCvef@phenom.ffwll.local>

Am 22.12.21 um 22:21 schrieb Daniel Vetter:
> On Tue, Dec 07, 2021 at 01:33:51PM +0100, Christian König wrote:
>> Add a function to simplify getting a single fence for all the fences in
>> the dma_resv object.
>>
>> v2: fix ref leak in error handling
>>
>> Signed-off-by: Christian König <christian.koenig@amd.com>
>> ---
>>   drivers/dma-buf/dma-resv.c | 52 ++++++++++++++++++++++++++++++++++++++
>>   include/linux/dma-resv.h   |  2 ++
>>   2 files changed, 54 insertions(+)
>>
>> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
>> index 480c305554a1..694716a3d66d 100644
>> --- a/drivers/dma-buf/dma-resv.c
>> +++ b/drivers/dma-buf/dma-resv.c
>> @@ -34,6 +34,7 @@
>>    */
>>   
>>   #include <linux/dma-resv.h>
>> +#include <linux/dma-fence-array.h>
>>   #include <linux/export.h>
>>   #include <linux/mm.h>
>>   #include <linux/sched/mm.h>
>> @@ -657,6 +658,57 @@ int dma_resv_get_fences(struct dma_resv *obj, bool write,
>>   }
>>   EXPORT_SYMBOL_GPL(dma_resv_get_fences);
>>   
>> +/**
>> + * dma_resv_get_singleton - Get a single fence for all the fences
>> + * @obj: the reservation object
>> + * @write: true if we should return all fences
>> + * @fence: the resulting fence
>> + *
>> + * Get a single fence representing all the fences inside the resv object.
>> + * Returns either 0 for success or -ENOMEM.
>> + *
>> + * Warning: This can't be used like this when adding the fence back to the resv
>> + * object since that can lead to stack corruption when finalizing the
>> + * dma_fence_array.
> Uh I don't get this one? I thought the only problem with nested fences is
> the signalling recursion, which we work around with the irq_work?

Nope, the main problem is finalizing the dma_fence_array.

E.g. imagine that you build up a chain of dma_fence_array objects like this:
a<-b<-c<-d<-e<-f.....

With each one referencing the previous dma_fence_array and then you call 
dma_fence_put() on the last one. That in turn will cause calling 
dma_fence_put() on the previous one, which in turn will cause 
dma_fence_put() one the one before the previous one etc....

In other words you recurse because each dma_fence_array instance drops 
the last reference of it's predecessor.

What we could do is to delegate dropping the reference to the containing 
fences in a dma_fence_array as well, but that would require some changes 
to the irq_work_run_list() function to be halve way efficient.

> Also if there's really an issue with dma_fence_array fences, then that
> warning should be on the dma_resv kerneldoc, not somewhere hidden like
> this. And finally I really don't see what can go wrong, sure we'll end up
> with the same fence once in the dma_resv_list and then once more in the
> fence array. But they're all refcounted, so really shouldn't matter.
>
> The code itself looks correct, but me not understanding what even goes
> wrong here freaks me out a bit.

Yeah, IIRC we already discussed that with Jason in length as well.

Essentially what you can't do is to put a dma_fence_array into another 
dma_fence_array without causing issues.

So I think we should maybe just add a WARN_ON() into 
dma_fence_array_init() to make sure that this never happens.

Regards,
Christian.

>
> I guess something to figure out next year, I kinda hoped I could squeeze a
> review in before I disappear :-/
> -Daniel
>
>> + */
>> +int dma_resv_get_singleton(struct dma_resv *obj, bool write,
>> +			   struct dma_fence **fence)
>> +{
>> +	struct dma_fence_array *array;
>> +	struct dma_fence **fences;
>> +	unsigned count;
>> +	int r;
>> +
>> +	r = dma_resv_get_fences(obj, write, &count, &fences);
>> +        if (r)
>> +		return r;
>> +
>> +	if (count == 0) {
>> +		*fence = NULL;
>> +		return 0;
>> +	}
>> +
>> +	if (count == 1) {
>> +		*fence = fences[0];
>> +		kfree(fences);
>> +		return 0;
>> +	}
>> +
>> +	array = dma_fence_array_create(count, fences,
>> +				       dma_fence_context_alloc(1),
>> +				       1, false);
>> +	if (!array) {
>> +		while (count--)
>> +			dma_fence_put(fences[count]);
>> +		kfree(fences);
>> +		return -ENOMEM;
>> +	}
>> +
>> +	*fence = &array->base;
>> +	return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(dma_resv_get_singleton);
>> +
>>   /**
>>    * dma_resv_wait_timeout - Wait on reservation's objects
>>    * shared and/or exclusive fences.
>> diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
>> index fa2002939b19..cdfbbda6f600 100644
>> --- a/include/linux/dma-resv.h
>> +++ b/include/linux/dma-resv.h
>> @@ -438,6 +438,8 @@ void dma_resv_replace_fences(struct dma_resv *obj, uint64_t context,
>>   void dma_resv_add_excl_fence(struct dma_resv *obj, struct dma_fence *fence);
>>   int dma_resv_get_fences(struct dma_resv *obj, bool write,
>>   			unsigned int *num_fences, struct dma_fence ***fences);
>> +int dma_resv_get_singleton(struct dma_resv *obj, bool write,
>> +			   struct dma_fence **fence);
>>   int dma_resv_copy_fences(struct dma_resv *dst, struct dma_resv *src);
>>   long dma_resv_wait_timeout(struct dma_resv *obj, bool wait_all, bool intr,
>>   			   unsigned long timeout);
>> -- 
>> 2.25.1
>>


  reply	other threads:[~2022-01-03 11:13 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-07 12:33 completely rework the dma_resv semantic Christian König
2021-12-07 12:33 ` [PATCH 01/24] dma-buf: add dma_resv_replace_fences Christian König
2021-12-22 21:05   ` Daniel Vetter
2021-12-22 21:05     ` Daniel Vetter
2022-01-03 10:48     ` Christian König
2022-01-03 10:48       ` Christian König
2022-01-14 16:28       ` Daniel Vetter
2022-01-14 16:28         ` Daniel Vetter
2021-12-07 12:33 ` [PATCH 02/24] dma-buf: finally make the dma_resv_list private Christian König
2021-12-22 21:08   ` Daniel Vetter
2021-12-22 21:08     ` Daniel Vetter
2021-12-07 12:33 ` [PATCH 03/24] dma-buf: drop excl_fence parameter from dma_resv_get_fences Christian König
2021-12-22 21:13   ` Daniel Vetter
2021-12-22 21:13     ` Daniel Vetter
2021-12-07 12:33 ` [PATCH 04/24] dma-buf: add dma_resv_get_singleton v2 Christian König
2021-12-22 21:21   ` Daniel Vetter
2021-12-22 21:21     ` Daniel Vetter
2022-01-03 11:13     ` Christian König [this message]
2022-01-03 11:13       ` Christian König
2022-01-14 16:31       ` Daniel Vetter
2022-01-14 16:31         ` Daniel Vetter
2022-01-17 11:26         ` Christian König
2022-01-17 11:26           ` Christian König
2022-03-02 17:39           ` Jason Ekstrand
2021-12-07 12:33 ` [PATCH 05/24] RDMA: use dma_resv_wait() instead of extracting the fence Christian König
2021-12-22 21:23   ` Daniel Vetter
2021-12-22 21:23     ` Daniel Vetter
2021-12-07 12:33 ` [PATCH 06/24] drm/etnaviv: stop using dma_resv_excl_fence Christian König
2021-12-22 21:26   ` Daniel Vetter
2021-12-22 21:26     ` Daniel Vetter
2021-12-07 12:33 ` [PATCH 07/24] drm/nouveau: " Christian König
2021-12-22 21:26   ` Daniel Vetter
2021-12-22 21:26     ` Daniel Vetter
2021-12-07 12:33 ` [PATCH 08/24] drm/vmwgfx: " Christian König
2021-12-22 21:31   ` Daniel Vetter
2021-12-22 21:31     ` Daniel Vetter
2021-12-07 12:33 ` [PATCH 09/24] drm/radeon: " Christian König
2021-12-22 21:30   ` Daniel Vetter
2021-12-22 21:30     ` Daniel Vetter
2021-12-07 12:33 ` [PATCH 10/24] drm/amdgpu: remove excl as shared workarounds Christian König
2021-12-22 21:34   ` Daniel Vetter
2021-12-22 21:34     ` Daniel Vetter
2021-12-07 12:33 ` [PATCH 11/24] drm/amdgpu: use dma_resv_for_each_fence for CS workaround Christian König
2021-12-22 21:37   ` Daniel Vetter
2021-12-22 21:37     ` Daniel Vetter
2022-01-03 12:24     ` Christian König
2022-01-03 12:24       ` Christian König
2021-12-07 12:33 ` [PATCH 12/24] dma-buf: finally make dma_resv_excl_fence private Christian König
2021-12-22 21:39   ` Daniel Vetter
2021-12-22 21:39     ` Daniel Vetter
2021-12-07 12:34 ` [PATCH 13/24] dma-buf: drop the DAG approach for the dma_resv object Christian König
2021-12-22 21:43   ` Daniel Vetter
2021-12-22 21:43     ` Daniel Vetter
2022-01-04 15:08     ` Christian König
2022-01-04 15:08       ` Christian König
2022-01-14 16:33       ` Daniel Vetter
2022-01-14 16:33         ` Daniel Vetter
2021-12-07 12:34 ` [PATCH 14/24] dma-buf/drivers: make reserving a shared slot mandatory v2 Christian König
2021-12-22 21:50   ` Daniel Vetter
2021-12-22 21:50     ` Daniel Vetter
2021-12-07 12:34 ` [PATCH 15/24] drm: support more than one write fence in drm_gem_plane_helper_prepare_fb Christian König
2021-12-22 21:51   ` Daniel Vetter
2021-12-22 21:51     ` Daniel Vetter
2021-12-07 12:34 ` [PATCH 16/24] drm/nouveau: support more than one write fence in fenv50_wndw_prepare_fb Christian König
2021-12-22 21:52   ` Daniel Vetter
2021-12-22 21:52     ` Daniel Vetter
2021-12-07 12:34 ` [PATCH 17/24] drm/amdgpu: use dma_resv_get_singleton in amdgpu_pasid_free_cb Christian König
2021-12-22 21:53   ` Daniel Vetter
2021-12-22 21:53     ` Daniel Vetter
2021-12-07 12:34 ` [PATCH 18/24] dma-buf: add enum dma_resv_usage v3 Christian König
2021-12-22 22:00   ` Daniel Vetter
2021-12-22 22:00     ` Daniel Vetter
2022-03-02 17:55     ` Jason Ekstrand
2022-03-03 13:13       ` Christian König
2021-12-07 12:34 ` [PATCH 19/24] dma-buf: specify usage while adding fences to dma_resv obj v2 Christian König
2021-12-07 12:34 ` [PATCH 20/24] dma-buf: add DMA_RESV_USAGE_KERNEL Christian König
2021-12-22 22:05   ` Daniel Vetter
2021-12-22 22:05     ` Daniel Vetter
2022-03-02 18:11     ` Jason Ekstrand
2022-03-03 13:49       ` Christian König
2021-12-07 12:34 ` [PATCH 21/24] dma-buf: add DMA_RESV_USAGE_BOOKKEEP Christian König
2021-12-22 22:10   ` Daniel Vetter
2021-12-22 22:10     ` Daniel Vetter
2021-12-07 12:34 ` [PATCH 22/24] dma-buf: wait for map to complete for static attachments Christian König
2021-12-22 22:16   ` Daniel Vetter
2021-12-22 22:16     ` Daniel Vetter
2021-12-07 12:34 ` [PATCH 23/24] amdgpu: remove DMA-buf fence workaround Christian König
2021-12-07 12:34 ` [PATCH 24/24] drm/ttm: remove bo->moving Christian König
2021-12-17 14:39 ` completely rework the dma_resv semantic Christian König
2021-12-22 22:17   ` Daniel Vetter
2021-12-22 22:17     ` Daniel Vetter
2021-12-23  9:11     ` Christian König
2021-12-23  9:11       ` Christian König
2022-01-14 16:35       ` Daniel Vetter
2022-01-14 16:35         ` Daniel Vetter

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=95929048-b381-78d1-462c-e7b910c784b0@gmail.com \
    --to=ckoenig.leichtzumerken@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-media@vger.kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.