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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 1 Feb 2023 07:48:11 -0800
From:   Rob Clark <robdclark@...omium.org>
To:     Dmitry Osipenko <dmitry.osipenko@...labora.com>
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 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.

BR,
-R