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@xxxxxxxxxxxxxxx>
> > >>> Cc: stable@xxxxxxxxxxxxxxx # 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
> > >
> > >>> }
> > >>>
> > >
> > >
> > >
> >
> >
>
>
