linux-kernel - Re: [PATCH v2] drm/syncobj: ensure progress for syncobj queries

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: <CAPaKu7QwSq7a-ipSOdETFEBGMu4J4ud1SqxDfPp8bNMjCMM5RQ@mail.gmail.com>
Date: Tue, 22 Oct 2024 10:24:40 -0700
From: Chia-I Wu <olvaffe@...il.com>
To: Christian König <christian.koenig@....com>
Cc: boris.brezillon@...labora.com, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>, 
	Chunming Zhou <david1.zhou@....com>, Lionel Landwerlin <lionel.g.landwerlin@...el.com>, 
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org, 
	faith.ekstrand@...labora.com
Subject: Re: [PATCH v2] drm/syncobj: ensure progress for syncobj queries

On Tue, Oct 22, 2024 at 9:53 AM Christian König
<christian.koenig@....com> wrote:
>
> Am 22.10.24 um 18:18 schrieb Chia-I Wu:
> > Userspace might poll a syncobj with the query ioctl.  Call
> > dma_fence_enable_sw_signaling to ensure dma_fence_is_signaled returns
> > true in finite time.
>
> Wait a second, just querying the fence status is absolutely not
> guaranteed to return true in finite time. That is well documented on the
> dma_fence() object.
>
> When you want to poll on signaling from userspace you really need to
> call poll or the wait IOCTL with a zero timeout. That will also return
> immediately but should enable signaling while doing that.
>
> So just querying the status should absolutely *not* enable signaling.
> That's an intentional separation.
I think it depends on what semantics DRM_IOCTL_SYNCOBJ_QUERY should have.

If DRM_IOCTL_SYNCOBJ_QUERY is mainly for vulkan timeline semaphores,
it is a bit heavy if userspace has to do a
DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT before a query.


>
> Regards,
> Christian.
>
> >
> > Fixes: 27b575a9aa2f ("drm/syncobj: add timeline payload query ioctl v6")
> > Signed-off-by: Chia-I Wu <olvaffe@...il.com>
> >
> > ---
> >
> > v2: add Signed-off-by and Fixes tags
> > ---
> >   drivers/gpu/drm/drm_syncobj.c | 3 +++
> >   1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> > index 4fcfc0b9b386c..58c5593c897a2 100644
> > --- a/drivers/gpu/drm/drm_syncobj.c
> > +++ b/drivers/gpu/drm/drm_syncobj.c
> > @@ -1689,6 +1689,9 @@ int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
> >                           DRM_SYNCOBJ_QUERY_FLAGS_LAST_SUBMITTED) {
> >                               point = fence->seqno;
> >                       } else {
> > +                             /* ensure forward progress */
> > +                             dma_fence_enable_sw_signaling(fence);
> > +
> >                               dma_fence_chain_for_each(iter, fence) {
> >                                       if (iter->context != fence->context) {
> >                                               dma_fence_put(iter);
>