linux-kernel - RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

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: <DD379D741F77464281CE7ED1CD7C12DE7065DDE5@SHSMSX101.ccr.corp.intel.com>
Date:   Fri, 19 May 2017 08:17:06 +0000
From:   "Chen, Xiaoguang" <xiaoguang.chen@...el.com>
To:     Gerd Hoffmann <kraxel@...hat.com>,
        Alex Williamson <alex.williamson@...hat.com>
CC:     "Tian, Kevin" <kevin.tian@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "zhenyuw@...ux.intel.com" <zhenyuw@...ux.intel.com>,
        "Lv, Zhiyuan" <zhiyuan.lv@...el.com>,
        "intel-gvt-dev@...ts.freedesktop.org" 
        <intel-gvt-dev@...ts.freedesktop.org>,
        "Wang, Zhi A" <zhi.a.wang@...el.com>
Subject: RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

Hi Gerd and Alex,

>-----Original Message-----
>From: Gerd Hoffmann [mailto:kraxel@...hat.com]
>Sent: Friday, May 19, 2017 4:05 PM
>To: Alex Williamson <alex.williamson@...hat.com>
>Cc: Chen, Xiaoguang <xiaoguang.chen@...el.com>; Tian, Kevin
><kevin.tian@...el.com>; linux-kernel@...r.kernel.org; zhenyuw@...ux.intel.com;
>Lv, Zhiyuan <zhiyuan.lv@...el.com>; intel-gvt-dev@...ts.freedesktop.org; Wang,
>Zhi A <zhi.a.wang@...el.com>
>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
>  Hi,
>
>> > User space need to check whether there's a dmabuf for the plane(user space
>usually cached two or three dmabuf to handle double buffer or triple buffer
>situation) only there's no dmabuf for the plane we will create a dmabuf for
>it(another ioctl).
>>
>> If our ioctls are "Query current plane" and "Give me a dmabuf for
>> current plane", isn't that racey?  The current plane could have
>> changed between those two calls so the user doesn't absolutely know
>> which plane the dmabuf retrieved is for.  The "Give me a dmabuf"
>> therefore needs to take some sort of plane index so the user can
>> request a specific plane.
>
>The "give me a dmabuf" ioctl returns the plane description too, so userspace can
>at least figure it did hit the race window.
>
>We could also do it the other way around:  Instead of having the kernel returning
>the plane description userspace could pass it in, and the kernel throws -EINVAL in
>case it doesn't match due to things having changed meanwhile.
Or just return a dmabuf  based on the current plane ?
Because if user got -EINVAL while ioctl "Give me a dmabuf" user should do the ioctl again.

>
>cheers,
>  Gerd