[Intel-gfx] [PATCH v14 5/7] vfio: ABI for mdev display dma-buf operation
Zhang, Tina
tina.zhang at intel.com
Fri Sep 29 09:08:29 UTC 2017
> -----Original Message-----
> From: Gerd Hoffmann [mailto:kraxel at redhat.com]
> Sent: Friday, September 29, 2017 4:03 PM
> To: Zhang, Tina <tina.zhang at intel.com>; zhenyuw at linux.intel.com; Wang, Zhi
> A <zhi.a.wang at intel.com>; Tian, Kevin <kevin.tian at intel.com>; Alex
> Williamson <alex.williamson at redhat.com>
> Cc: Daniel Vetter <daniel.vetter at ffwll.ch>; intel-gfx at lists.freedesktop.org;
> intel-gvt-dev at lists.freedesktop.org; Lv, Zhiyuan <zhiyuan.lv at intel.com>
> Subject: Re: [PATCH v14 5/7] vfio: ABI for mdev display dma-buf operation
>
> Hi,
>
> > > > Does the generic way need the close ioctl?
> > >
> > > I think we don't need a close ioctl anyway.
> >
> > Can you share your thoughts?
>
> See other mail. I think the race can be fixed by changing the locking, so a explicit
> close ioctl isn't needed.
Yeah, I understand your idea. But unfortunately, it cannot solve the current issue.
There will still be a racing condition between releasing dmabuf_obj and reusing it.
For example, if the old reused dmabuf_obj is released just after query ioctl return it, the next get_fd ioctl would
return error as the dmabuf_obj has already been closed.
>
> > Do you think the fd interface is enough for all kinds of buffer
> > exposed by Mdev?
>
> What kind of buffers do you have in mind which might not be covered?
I thinking about the case that would like to postpone the buffers releasing operation, after user space has closed all the fd.
Later these buffers may be used to expose to other kinds of fd to user space.
Thanks.
BR,
Tina
>
> cheers,
> Gerd
More information about the Intel-gfx
mailing list