Re: [PATCH] drm/virtio: exbuf->fence_fd unmodified on interrupted wait

[Dmitry Osipenko <dmitry.osipenko@collabora.com>]

On 2/2/23 05:17, Dmitry Osipenko wrote:
> On 2/1/23 18:48, Rob Clark wrote:
>> On Wed, Feb 1, 2023 at 5:28 AM Dmitry Osipenko
>> <dmitry.osipenko@collabora.com> wrote:
>>>
>>> On 1/27/23 01:58, Ryan Neph wrote:
>>>> An interrupted dma_fence_wait() becomes an -ERESTARTSYS returned
>>>> to userspace ioctl(DRM_IOCTL_VIRTGPU_EXECBUFFER) calls, prompting to
>>>> retry the ioctl(), but the passed exbuf->fence_fd has been reset to -1,
>>>> making the retry attempt fail at sync_file_get_fence().
>>>>
>>>> The uapi for DRM_IOCTL_VIRTGPU_EXECBUFFER is changed to retain the
>>>> passed value for exbuf->fence_fd when returning ERESTARTSYS or EINTR.
>>>>
>>>> Fixes: 2cd7b6f08bc4 ("drm/virtio: add in/out fence support for explicit synchronization")
>>>> Signed-off-by: Ryan Neph <ryanneph@chromium.org>
>>>> ---
>>>>
>>>>  drivers/gpu/drm/virtio/virtgpu_ioctl.c | 9 ++++++---
>>>>  include/uapi/drm/virtgpu_drm.h         | 3 +++
>>>>  2 files changed, 9 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
>>>> index 9f4a90493aea..ffce4e2a409a 100644
>>>> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
>>>> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
>>>> @@ -132,6 +132,8 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device *dev, void *data,
>>>>       uint64_t fence_ctx;
>>>>       uint32_t ring_idx;
>>>>
>>>> +     exbuf->fence_fd = -1;
>>>> +
>>>>       fence_ctx = vgdev->fence_drv.context;
>>>>       ring_idx = 0;
>>>>
>>>> @@ -152,8 +154,6 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device *dev, void *data,
>>>>               ring_idx = exbuf->ring_idx;
>>>>       }
>>>>
>>>> -     exbuf->fence_fd = -1;
>>>
>>> Is there any userspace relying on this -1 behaviour? Wouldn't be better
>>> to remove this offending assignment?
>>
>> Looking at current mesa, removing the assignment should be ok (and
>> more consistent with other drivers).  But I can't say if this was
>> always true, or that there aren't other non-mesa users, so I can see
>> the argument for the more conservative uabi change that this patch
>> went with.
> 
> Realistically, Mesa is the only user of this IOCTL. In general, in a
> such case of doubt, I'll do the UABI change and then wait for complains.
> If there is a complaint, then the change is reverted. Also will be good
> to know about existence of other users :)
> 
> Given that -1 already wasn't consistently set for all error code paths,
> it's tempting to see it removed.
> 
> The code change of this patch is trivial, hence should fine to keep the
> -1 if you prefer that, but the patch won't apply cleanly to the stable
> kernels because of the "exbuf->fence_fd = -1" movement. If stable
> maintainers won't put effort into rebasing the patch, then better to do
> the removal and live with a cleaner driver code, IMO.

Although, there will be a merge conflict either way. I'll give the r-b,
still removing -1 feels more attractive to me.

-- 
Best regards,
Dmitry