linux-kernel - Re: [PATCH] drm/virtio: exbuf->fence

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 2 Feb 2023 05:17:41 +0300
From:   Dmitry Osipenko <dmitry.osipenko@...labora.com>
To:     Rob Clark <robdclark@...omium.org>
Cc:     Ryan Neph <ryanneph@...omium.org>,
        David Airlie <airlied@...hat.com>,
        Gerd Hoffmann <kraxel@...hat.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Gurchetan Singh <gurchetansingh@...omium.org>,
        Chia-I Wu <olvaffe@...il.com>, dri-devel@...ts.freedesktop.org,
        virtualization@...ts.linux-foundation.org,
        linux-kernel@...r.kernel.org, Yiwei Zhang <zzyiwei@...omium.org>,
        Gustavo Padovan <gustavo.padovan@...labora.com>,
        Emil Velikov <emil.velikov@...labora.com>
Subject: Re: [PATCH] drm/virtio: exbuf->fence_fd unmodified on interrupted
 wait

On 2/1/23 18:48, Rob Clark wrote:
> On Wed, Feb 1, 2023 at 5:28 AM Dmitry Osipenko
> <dmitry.osipenko@...labora.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@...omium.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.

-- 
Best regards,
Dmitry