> -----Original Message----- > From: Gerd Hoffmann [mailto:[email protected]] > Sent: Friday, September 29, 2017 4:03 PM > To: Zhang, Tina <[email protected]>; [email protected]; Wang, Zhi > A <[email protected]>; Tian, Kevin <[email protected]>; Alex > Williamson <[email protected]> > Cc: Daniel Vetter <[email protected]>; [email protected]; > [email protected]; Lv, Zhiyuan <[email protected]> > 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 _______________________________________________ Intel-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/intel-gfx
