Hi, > 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. My branch already grabs an extra reference when creating a new dmabuf_obj, which will be dropped on GET_DMABUF ioctl, exactly to avoid the dmabuf_obj disappear between QUERY_PLANE and GET_DMABUF ioctls. Can easily be extended to handle the reuse case too. https://www.kraxel.org/cgit/linux/commit/?h=gvt-dmabuf-v14&id=9959109ae 52cf15e119715a6b7de080fb849e3d2 While being at it also cleanup properly on close (so we don't leak structs in case userspace never calls GET_DMABUF for a plane). https://www.kraxel.org/cgit/linux/commit/?h=gvt-dmabuf-v14&id=c0b0c407e 33904e749dec1ef44ec01099c16d39f > > > 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. Work fine. qemu can import the dma-buf as opengl texture, which creates a extra reference. Then close the fd. dma-buf continues to exist as long as the texture referencing it exists. > Later these buffers may be used to expose to other kinds of fd to > user space. Sorry, I don't understand that sentence. cheers, Gerd _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
