All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
To: Ryan Neph <ryanneph@chromium.org>,
	David Airlie <airlied@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Gurchetan Singh <gurchetansingh@chromium.org>,
	Chia-I Wu <olvaffe@gmail.com>,
	dri-devel@lists.freedesktop.org,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org
Cc: Yiwei Zhang <zzyiwei@chromium.org>,
	Rob Clark <robdclark@chromium.org>,
	Rob Clark <robdclark@gmail.com>,
	Emil Velikov <emil.velikov@collabora.com>,
	Gustavo Padovan <gustavo.padovan@collabora.com>
Subject: Re: [PATCH v2] drm/virtio: exbuf->fence_fd unmodified on interrupted wait
Date: Mon, 6 Feb 2023 20:20:46 +0300	[thread overview]
Message-ID: <c06c005d-41a8-5403-818b-f66264fe8c0b@collabora.com> (raw)
In-Reply-To: <20230203233345.2477767-1-ryanneph@chromium.org>

On 2/4/23 02:33, 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 anything besides a
> successful result from the ioctl.
> 
> Fixes: 2cd7b6f08bc4 ("drm/virtio: add in/out fence support for explicit synchronization")
> Signed-off-by: Ryan Neph <ryanneph@chromium.org>
> Reviewed-by: Rob Clark <robdclark@gmail.com>
> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> 
> ---
> 
> Changes in v2:
> - No longer modifies exbuf->fence_fd unless DRM_IOCTL_VIRTGPU_EXECBUFFER
>   succeeds.
> - Added r-b tags (Rob/Dmitry) from v1.

Thanks! Applied to misc-fixes

-- 
Best regards,
Dmitry


WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
To: Ryan Neph <ryanneph@chromium.org>,
	David Airlie <airlied@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Gurchetan Singh <gurchetansingh@chromium.org>,
	Chia-I Wu <olvaffe@gmail.com>,
	dri-devel@lists.freedesktop.org,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org
Cc: Rob Clark <robdclark@chromium.org>,
	Yiwei Zhang <zzyiwei@chromium.org>,
	Gustavo Padovan <gustavo.padovan@collabora.com>,
	Emil Velikov <emil.velikov@collabora.com>
Subject: Re: [PATCH v2] drm/virtio: exbuf->fence_fd unmodified on interrupted wait
Date: Mon, 6 Feb 2023 20:20:46 +0300	[thread overview]
Message-ID: <c06c005d-41a8-5403-818b-f66264fe8c0b@collabora.com> (raw)
In-Reply-To: <20230203233345.2477767-1-ryanneph@chromium.org>

On 2/4/23 02:33, 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 anything besides a
> successful result from the ioctl.
> 
> Fixes: 2cd7b6f08bc4 ("drm/virtio: add in/out fence support for explicit synchronization")
> Signed-off-by: Ryan Neph <ryanneph@chromium.org>
> Reviewed-by: Rob Clark <robdclark@gmail.com>
> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> 
> ---
> 
> Changes in v2:
> - No longer modifies exbuf->fence_fd unless DRM_IOCTL_VIRTGPU_EXECBUFFER
>   succeeds.
> - Added r-b tags (Rob/Dmitry) from v1.

Thanks! Applied to misc-fixes

-- 
Best regards,
Dmitry


  reply	other threads:[~2023-02-06 17:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-03 23:33 [PATCH v2] drm/virtio: exbuf->fence_fd unmodified on interrupted wait Ryan Neph
2023-02-03 23:33 ` Ryan Neph
2023-02-06 17:20 ` Dmitry Osipenko [this message]
2023-02-06 17:20   ` Dmitry Osipenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c06c005d-41a8-5403-818b-f66264fe8c0b@collabora.com \
    --to=dmitry.osipenko@collabora.com \
    --cc=airlied@redhat.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emil.velikov@collabora.com \
    --cc=gurchetansingh@chromium.org \
    --cc=gustavo.padovan@collabora.com \
    --cc=kraxel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olvaffe@gmail.com \
    --cc=robdclark@chromium.org \
    --cc=robdclark@gmail.com \
    --cc=ryanneph@chromium.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=zzyiwei@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.