linux-kernel - Re: [RFC][PATCH 2/3] drm: vgem: Enable SYNCOBJ and SYNCOBJ

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]

Date:   Wed, 13 Jul 2022 10:02:12 +0200
From:   Christian König <christian.koenig@....com>
To:     John Stultz <jstultz@...gle.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Jason Ekstrand <jason@...kstrand.net>,
        Lionel Landwerlin <lionel.g.landwerlin@...el.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        dri-devel@...ts.freedesktop.org
Subject: Re: [RFC][PATCH 2/3] drm: vgem: Enable SYNCOBJ and SYNCOBJ_TIMELINE
 on vgem driver

Am 12.07.22 um 18:50 schrieb John Stultz:
> On Tue, Jul 12, 2022 at 12:46 AM Christian König
> <christian.koenig@....com> wrote:
>> Am 12.07.22 um 06:22 schrieb John Stultz:
>>> Allows for basic SYNCOBJ api testing, in environments
>>> like VMs where there may not be a supported drm driver.
>>>
>>> Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
>>> Cc: Maxime Ripard <mripard@...nel.org>
>>> Cc: Thomas Zimmermann <tzimmermann@...e.de>
>>> Cc: Jason Ekstrand <jason@...kstrand.net>
>>> Cc: Christian König <christian.koenig@....com>
>>> Cc: Lionel Landwerlin <lionel.g.landwerlin@...el.com>
>>> Cc: Chunming Zhou <david1.zhou@....com>
>>> Cc: David Airlie <airlied@...ux.ie>
>>> Cc: Daniel Vetter <daniel@...ll.ch>
>>> Cc: dri-devel@...ts.freedesktop.org
>>> Signed-off-by: John Stultz <jstultz@...gle.com>
>>> ---
>>>    drivers/gpu/drm/vgem/vgem_drv.c | 3 ++-
>>>    1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
>>> index c5e3e5457737..e5427d7399da 100644
>>> --- a/drivers/gpu/drm/vgem/vgem_drv.c
>>> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
>>> @@ -109,7 +109,8 @@ static struct drm_gem_object *vgem_gem_create_object(struct drm_device *dev, siz
>>>    }
>>>
>>>    static const struct drm_driver vgem_driver = {
>>> -     .driver_features                = DRIVER_GEM | DRIVER_RENDER,
>>> +     .driver_features                = DRIVER_GEM | DRIVER_RENDER |
>>> +                                       DRIVER_SYNCOBJ | DRIVER_SYNCOBJ_TIMELINE,
>> Well that's rather surprising. I'm not an export on VGEM, but AFAIK you
>> need to adjust the CS interface to support that stuff as well.
> Apologies, could you clarify a bit more what you mean here?  This was
> just helpful to enable the generic userland ioctls for the example
> test tool in this series.
>
> Are you proposing to add interfaces so the vgem driver can
> attach/signal syncobjs similar to the
> DRM_IOCTL_VGEM_FENCE_ATTACH/DRM_IOCTL_VGEM_FENCE_SIGNAL calls?

Yes, exactly that. I don't see how it would be useful otherwise.

Christian.

>
> thanks
> -john