Re: [PATCH] drm/i915: Move fd_install after last use of fence

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 03/02/2023 18:15, Rob Clark wrote:
> On Fri, Feb 3, 2023 at 8:49 AM Rob Clark <robdclark@gmail.com> wrote:
>>
>> From: Rob Clark <robdclark@chromium.org>
>>
>> Because eb_composite_fence_create() drops the fence_array reference
>> after creation of the sync_file, only the sync_file holds a ref to the
>> fence.  But fd_install() makes that reference visable to userspace, so
>> it must be the last thing we do with the fence.
>>
> 
> Fixes: 00dae4d3d35d ("drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)")

This is correct and the fix looks good to me.

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

CI is green so I will merge it, thanks again for a fix Rob!

Followup up question for Matthew Brost however is whether the composite 
fence flow could be simplified. This block here comes late in 
i915_gem_do_execbuffer and may mislead the user the composite fence is 
held to the end of the function:

	if (!out_fence && eb.composite_fence)
		dma_fence_put(eb.composite_fence);

Question is would it work to remove the !out_fence condition from here, 
and remove "consumption" of the reference from eb_composite_fence_create 
success path.

Regards,

Tvrtko

>> Signed-off-by: Rob Clark <robdclark@chromium.org>
>> ---
>>   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 14 +++++++-------
>>   1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>> index f266b68cf012..0f2e056c02dd 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>> @@ -3476,38 +3476,38 @@ i915_gem_do_execbuffer(struct drm_device *dev,
>>
>>   err_request:
>>          eb_requests_get(&eb);
>>          err = eb_requests_add(&eb, err);
>>
>>          if (eb.fences)
>>                  signal_fence_array(&eb, eb.composite_fence ?
>>                                     eb.composite_fence :
>>                                     &eb.requests[0]->fence);
>>
>> +       if (unlikely(eb.gem_context->syncobj)) {
>> +               drm_syncobj_replace_fence(eb.gem_context->syncobj,
>> +                                         eb.composite_fence ?
>> +                                         eb.composite_fence :
>> +                                         &eb.requests[0]->fence);
>> +       }
>> +
>>          if (out_fence) {
>>                  if (err == 0) {
>>                          fd_install(out_fence_fd, out_fence->file);
>>                          args->rsvd2 &= GENMASK_ULL(31, 0); /* keep in-fence */
>>                          args->rsvd2 |= (u64)out_fence_fd << 32;
>>                          out_fence_fd = -1;
>>                  } else {
>>                          fput(out_fence->file);
>>                  }
>>          }
>>
>> -       if (unlikely(eb.gem_context->syncobj)) {
>> -               drm_syncobj_replace_fence(eb.gem_context->syncobj,
>> -                                         eb.composite_fence ?
>> -                                         eb.composite_fence :
>> -                                         &eb.requests[0]->fence);
>> -       }
>> -
>>          if (!out_fence && eb.composite_fence)
>>                  dma_fence_put(eb.composite_fence);
>>
>>          eb_requests_put(&eb);
>>
>>   err_vma:
>>          eb_release_vmas(&eb, true);
>>          WARN_ON(err == -EDEADLK);
>>          i915_gem_ww_ctx_fini(&eb.ww);
>>
>> --
>> 2.38.1
>>