[Intel-gfx] [PATCH v2 2/2] drm/i915: Never return 0 if not all requests retired

[Janusz Krzysztofik]

On Monday, 21 November 2022 11:51:15 CET Janusz Krzysztofik wrote:
> Hi Andrzej,
> 
> Thanks for your comment.
> 
> On Monday, 21 November 2022 11:17:42 CET Andrzej Hajda wrote:
> > 
> > On 21.11.2022 09:30, Janusz Krzysztofik wrote:
> > > Hi Nimroy,
> > >
> > > Thanks for looking at this.
> > >
> > > On Friday, 18 November 2022 20:56:50 CET Das, Nirmoy wrote:
> > >> On 11/18/2022 11:42 AM, Janusz Krzysztofik wrote:
> > >>> Users of intel_gt_retire_requests_timeout() expect 0 return value on
> > >>> success.  However, we have no protection from passing back 0 potentially
> > >>> returned by a call to dma_fence_wait_timeout() when it succedes right
> > >>> after its timeout has expired.
> > >>>
> > >>> Replace 0 with -ETIME before potentially using the timeout value as return
> > >>> code, so -ETIME is returned if there are still some requests not retired
> > >>> after timeout, 0 otherwise.
> > >>>
> > >>> v2: Move the added lines down so flush_submission() is not affected.
> > >>>
> > >>> Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with
> > > retire_request")
> > >>> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik at linux.intel.com>
> > >>> Cc: stable at vger.kernel.org # v5.5+
> > >>> ---
> > >>>    drivers/gpu/drm/i915/gt/intel_gt_requests.c | 3 +++
> > >>>    1 file changed, 3 insertions(+)
> > >>>
> > >>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c b/drivers/gpu/
> > > drm/i915/gt/intel_gt_requests.c
> > >>> index edb881d756309..3ac4603eeb4ee 100644
> > >>> --- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
> > >>> +++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
> > >>> @@ -199,6 +199,9 @@ out_active:	spin_lock(&timelines->lock);
> > >>>    	if (remaining_timeout)
> > >>>    		*remaining_timeout = timeout;
> > >>>    
> > >>> +	if (!timeout)
> > >>> +		timeout = -ETIME;
> > >> This will return error, -ETIME when 0 timeout is passed,
> > >> intel_gt_retire_requests().
> > > Yes, but only when active_count is not 0 after we loop through
> > > timelines->active_list calling retire_requests() on each and counting up
> > > failures in active_count.
> > 
> > Moving this line just after the call to dma_fence_wait_timeout should 
> > solve the controversy.
> 
> But that would break our need to pass 0, not -ETIME, to flush_submission() in 
> case the initial value of timeout was 0, as pointed out by Chris during our 
> discussion on v2.
> 
> Maybe an inline comment above the added lines that explains why we are doing 
> this could help?

How about not adding those two lines but modifying the return line instead?

-	return active_count ? timeout : 0;
+	return active_count ? timeout ?: -ETIME : 0;

Would that be self explanatory?

Thanks,
Janusz

> 
> Thanks,
> Janusz
> 
> > 
> > Regards
> > Andrzej
> > 
> > >
> > >> We don't want that.
> > > When 0 timeout is passed to intel_gt_retire_requests(), do we really want it
> > > to return 0 unconditionally, or are we rather interested if those calls to
> > > retire_requests() succeeded?
> > >
> > >> I think you can use a separate variable to store
> > >> return val from the dma_fence_wait_timeout()
> > >>
> > >>
> > >> Regards,
> > >>
> > >> Nirmoy
> > >>
> > >>> +
> > >>>    	return active_count ? timeout : 0;
> > > If active count is 0, we return 0 regardless of timeout value, and that's OK.
> > > However, if active_count is not 0, we shouldn't return 0, I believe, we should
> > > return either remaining time if some left, or error (-ETIME) if not.  If you
> > > think I'm wrong, please explain why.
> > >
> > > Thanks,
> > > Janusz
> > >
> > >>>    }
> > >>>    
> > >
> > >
> > >
> > 
> > 
> 
>