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]

Message-ID: <dee14d1b-fc28-e867-b425-ab11c31d799d@collabora.com>
Date:   Wed, 1 Feb 2023 16:28:19 +0300
From:   Dmitry Osipenko <dmitry.osipenko@...labora.com>
To:     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
Cc:     Rob Clark <robdclark@...omium.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 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?

-- 
Best regards,
Dmitry