Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>,
	dri-devel@lists.freedesktop.org
Cc: Sumit Semwal <sumit.semwal@linaro.org>,
	Gustavo Padovan <gustavo@padovan.org>,
	Matthew Brost <matthew.brost@intel.com>,
	Lucas De Marchi <lucas.demarchi@intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	amd-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	intel-gfx@lists.freedesktop.org, linux-media@vger.kernel.org,
	linaro-mm-sig@lists.linaro.org, kernel-dev@igalia.com
Subject: Re: [RFC v2 04/13] dma-fence: Move array and chain checks to flags
Date: Mon, 12 May 2025 19:57:12 +0200	[thread overview]
Message-ID: <bb7a5c06-2e93-4088-a5bc-9ca4f5304eab@amd.com> (raw)
In-Reply-To: <34263299-6279-44a2-a224-6a094a319ea6@igalia.com>

On 5/12/25 11:14, Tvrtko Ursulin wrote:
> 
> On 12/05/2025 09:19, Christian König wrote:
>> On 5/9/25 17:33, Tvrtko Ursulin wrote:
>>> With the goal of reducing the need for drivers to touch fence->ops, we
>>> add explicit flags for struct dma_fence_array and struct dma_fence_chain
>>> and make the respective helpers (dma_fence_is_array() and
>>> dma_fence_is_chain()) use them.
>>>
>>> This also allows us to remove the exported symbols for the respective
>>> operation tables.
>>
>> That looks like overkill to me. We don't de-reference the ops for the check, instead just the values are compared.
>>
>> Since the array and chain are always build in that should be completely unproblematic for driver unload.
> 
> You are right this is not strictly needed. Idea was just to reduce any access to ops as much as we can and this fell under that scope.
> 
> Another benefit one could perhaps argue is two fewer EXPORT_SYMBOLs, which is perhaps a little bit cleaner design (less exporting of implementation details to the outside), but it is not a super strong argument.


I would rather say that using the symbols improves things. Background is that otherwise every driver could accidentally or because of malicious intend set this flag.

The symbol is not so easily changeable.

Regards,
Christian. 

> 
> If we will not be going for this one then I would be taking 1/13 via drm-intel-gt-next.
> 
> Regards,
> 
> Tvrtko
> 
>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
>>> ---
>>>   drivers/dma-buf/dma-fence-array.c | 2 +-
>>>   drivers/dma-buf/dma-fence-chain.c | 2 +-
>>>   include/linux/dma-fence.h         | 9 ++++-----
>>>   3 files changed, 6 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-fence-array.c
>>> index 6657d4b30af9..daf444f5d228 100644
>>> --- a/drivers/dma-buf/dma-fence-array.c
>>> +++ b/drivers/dma-buf/dma-fence-array.c
>>> @@ -167,7 +167,6 @@ const struct dma_fence_ops dma_fence_array_ops = {
>>>       .release = dma_fence_array_release,
>>>       .set_deadline = dma_fence_array_set_deadline,
>>>   };
>>> -EXPORT_SYMBOL(dma_fence_array_ops);
>>>     /**
>>>    * dma_fence_array_alloc - Allocate a custom fence array
>>> @@ -207,6 +206,7 @@ void dma_fence_array_init(struct dma_fence_array *array,
>>>       spin_lock_init(&array->lock);
>>>       dma_fence_init(&array->base, &dma_fence_array_ops, &array->lock,
>>>                  context, seqno);
>>> +    __set_bit(DMA_FENCE_FLAG_ARRAY_BIT, &array->base.flags);
>>>       init_irq_work(&array->work, irq_dma_fence_array_work);
>>>         atomic_set(&array->num_pending, signal_on_any ? 1 : num_fences);
>>> diff --git a/drivers/dma-buf/dma-fence-chain.c b/drivers/dma-buf/dma-fence-chain.c
>>> index a8a90acf4f34..f4abe41fb092 100644
>>> --- a/drivers/dma-buf/dma-fence-chain.c
>>> +++ b/drivers/dma-buf/dma-fence-chain.c
>>> @@ -225,7 +225,6 @@ const struct dma_fence_ops dma_fence_chain_ops = {
>>>       .release = dma_fence_chain_release,
>>>       .set_deadline = dma_fence_chain_set_deadline,
>>>   };
>>> -EXPORT_SYMBOL(dma_fence_chain_ops);
>>>     /**
>>>    * dma_fence_chain_init - initialize a fence chain
>>> @@ -263,6 +262,7 @@ void dma_fence_chain_init(struct dma_fence_chain *chain,
>>>         dma_fence_init64(&chain->base, &dma_fence_chain_ops, &chain->lock,
>>>                context, seqno);
>>> +    __set_bit(DMA_FENCE_FLAG_CHAIN_BIT, &chain->base.flags);
>>>         /*
>>>        * Chaining dma_fence_chain container together is only allowed through
>>> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
>>> index ac6535716dbe..5bafd0a5f1f1 100644
>>> --- a/include/linux/dma-fence.h
>>> +++ b/include/linux/dma-fence.h
>>> @@ -98,6 +98,8 @@ struct dma_fence {
>>>     enum dma_fence_flag_bits {
>>>       DMA_FENCE_FLAG_SEQNO64_BIT,
>>> +    DMA_FENCE_FLAG_ARRAY_BIT,
>>> +    DMA_FENCE_FLAG_CHAIN_BIT,
>>>       DMA_FENCE_FLAG_SIGNALED_BIT,
>>>       DMA_FENCE_FLAG_TIMESTAMP_BIT,
>>>       DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
>>> @@ -632,9 +634,6 @@ struct dma_fence *dma_fence_get_stub(void);
>>>   struct dma_fence *dma_fence_allocate_private_stub(ktime_t timestamp);
>>>   u64 dma_fence_context_alloc(unsigned num);
>>>   -extern const struct dma_fence_ops dma_fence_array_ops;
>>> -extern const struct dma_fence_ops dma_fence_chain_ops;
>>> -
>>>   /**
>>>    * dma_fence_is_array - check if a fence is from the array subclass
>>>    * @fence: the fence to test
>>> @@ -643,7 +642,7 @@ extern const struct dma_fence_ops dma_fence_chain_ops;
>>>    */
>>>   static inline bool dma_fence_is_array(struct dma_fence *fence)
>>>   {
>>> -    return fence->ops == &dma_fence_array_ops;
>>> +    return test_bit(DMA_FENCE_FLAG_ARRAY_BIT, &fence->flags);
>>>   }
>>>     /**
>>> @@ -654,7 +653,7 @@ static inline bool dma_fence_is_array(struct dma_fence *fence)
>>>    */
>>>   static inline bool dma_fence_is_chain(struct dma_fence *fence)
>>>   {
>>> -    return fence->ops == &dma_fence_chain_ops;
>>> +    return test_bit(DMA_FENCE_FLAG_CHAIN_BIT, &fence->flags);
>>>   }
>>>     /**
>>
> 


  reply	other threads:[~2025-05-12 17:57 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-09 15:33 [RFC v2 00/13] Some (drm_sched_|dma_)fence lifetime issues Tvrtko Ursulin
2025-05-09 15:33 ` [RFC v2 01/13] drm/i915: Use provided dma_fence_is_chain Tvrtko Ursulin
2025-05-09 15:47   ` Matthew Brost
2025-05-12  8:05     ` Christian König
2025-05-12  8:11       ` Tvrtko Ursulin
2025-05-09 15:33 ` [RFC v2 02/13] dma-fence: Change signature of __dma_fence_is_later Tvrtko Ursulin
2025-05-12  8:13   ` Christian König
2025-05-09 15:33 ` [RFC v2 03/13] dma-fence: Use a flag for 64-bit seqnos Tvrtko Ursulin
2025-05-12  8:12   ` Tvrtko Ursulin
2025-05-12  8:17   ` Christian König
2025-05-12  9:20     ` Tvrtko Ursulin
2025-05-09 15:33 ` [RFC v2 04/13] dma-fence: Move array and chain checks to flags Tvrtko Ursulin
2025-05-12  8:19   ` Christian König
2025-05-12  9:14     ` Tvrtko Ursulin
2025-05-12 17:57       ` Christian König [this message]
2025-05-09 15:33 ` [RFC v2 05/13] dma-fence: Add helpers for accessing driver and timeline name Tvrtko Ursulin
2025-05-12  8:20   ` Christian König
2025-05-09 15:33 ` [RFC v2 06/13] dma-fence: Use driver and timeline name helpers internally Tvrtko Ursulin
2025-05-12  8:22   ` Christian König
2025-05-12  9:05     ` Tvrtko Ursulin
2025-05-09 15:33 ` [RFC v2 07/13] sync_file: Use dma-fence driver and timeline name helpers Tvrtko Ursulin
2025-05-12  8:25   ` Christian König
2025-05-09 15:33 ` [RFC v2 08/13] drm/amdgpu: " Tvrtko Ursulin
2025-05-12  8:27   ` Christian König
2025-05-12  9:07     ` Tvrtko Ursulin
2025-05-09 15:33 ` [RFC v2 09/13] drm/i915: " Tvrtko Ursulin
2025-05-12  8:28   ` Christian König
2025-05-09 15:33 ` [RFC v2 10/13] dma-fence: Add safe access helpers and document the rules Tvrtko Ursulin
2025-05-13 14:16   ` Rob Clark
2025-05-14 10:01     ` Tvrtko Ursulin
2025-05-14 13:57       ` Rob Clark
2025-05-14 14:58         ` Tvrtko Ursulin
2025-05-14 15:38           ` Rob Clark
2025-05-09 15:33 ` [RFC v2 11/13] sync_file: Protect access to driver and timeline name Tvrtko Ursulin
2025-05-09 15:33 ` [RFC v2 12/13] drm/i915: " Tvrtko Ursulin
2025-05-09 15:33 ` [RFC v2 13/13] drm/xe: Make dma-fences compliant with the safe access rules Tvrtko Ursulin
2025-05-12 14:11   ` Matthew Brost

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=bb7a5c06-2e93-4088-a5bc-9ca4f5304eab@amd.com \
    --to=christian.koenig@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavo@padovan.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=kernel-dev@igalia.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-media@vger.kernel.org \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.brost@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=sumit.semwal@linaro.org \
    --cc=tvrtko.ursulin@igalia.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox