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] [day] [month] [year] [list]
Message-ID: <CAPaKu7TB30wvDvMW2FcYNcxjfDkOje358JNnRr2jJf=99-h-rg@mail.gmail.com>
Date: Mon, 4 Nov 2024 13:32:47 -0800
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>, 
	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, simona@...ll.ch
Subject: Re: [PATCH v2] drm/syncobj: ensure progress for syncobj queries

On Tue, Oct 22, 2024 at 10:24 AM Chia-I Wu <olvaffe@...il.com> wrote:
>
> 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.

I filed a Mesa issue,
https://gitlab.freedesktop.org/mesa/mesa/-/issues/12094, and Faith
suggested a kernel-side fix as well.  Should we reconsider this?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ