linux-kernel - Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

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: <1498543954.15306.2.camel@redhat.com>
Date:   Tue, 27 Jun 2017 08:12:34 +0200
From:   Gerd Hoffmann <kraxel@...hat.com>
To:     Alex Williamson <alex.williamson@...hat.com>
Cc:     "Zhang, Tina" <tina.zhang@...el.com>,
        "intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Kirti Wankhede <kwankhede@...dia.com>,
        "Chen, Xiaoguang" <xiaoguang.chen@...el.com>,
        "intel-gvt-dev@...ts.freedesktop.org" 
        <intel-gvt-dev@...ts.freedesktop.org>,
        "Lv, Zhiyuan" <zhiyuan.lv@...el.com>,
        "Wang, Zhi A" <zhi.a.wang@...el.com>,
        "Wang, Zhenyu Z" <zhenyu.z.wang@...el.com>
Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf
 operations

  Hi,

> Hmm, I don't like that interface.  Can you cite examples of other
> ioctls that behave this way?  It doesn't feel like an elegant user
> interface; the user can get the dmabuf, but only after they query the
> dmabuf, even though the get-dmabuf ioctl returns the same data as the
> query-plane ioctl, but they can't get the dmabuf if the plane has
> changed in the interim, which is not something the user can
> know.  Are
> we causing our own problems with this model of cycling through dmabuf
> fds?  We talked previously about an enum of plane types, primary and
> cursor.  What if the user was simply able to get a dmabuf fd for each
> of
> those and they queried the current plane information via those fds?
> IOW, the fd is persistent and specific to a given plane type, but the
> format within it is dynamic.

Will not work due to how dma-bufs are designed.

But, yes, the QUERY then GET split is ugly for a number of reasons.

Does gvt track the live cycle of all dma-bufs it has handed out?
If so, then maybe we can let the kernel check whenever a dma-buf for
the current plane exists?  And if that isn't the case hand out a dma-
buf right away, without expecting userspace explicitly asking for it?

That will simplify the interface and remove the race condition at the
expense of some additional bookkeeping in the kernel.

cheers,
  Gerd