[Mesa-dev] [PATCH] intel: Track known prime buffers for re-use

[Keith Packard]

Daniel Vetter <daniel at ffwll.ch> writes:

> The kernel actually doesn't bother with this, i.e. an open on an flink
> name will always create a new handle. Given that it was a major pita to
> get the prime reimporting going (due to a pile of funny lifetime issues
> around reference loops and some assorted locking fun) I'm not volunteering
> to fix this ;-) And I also think that a piece of userspace which both
> flink-opens and prime imports on the same buffer gets both pieces.

That seems pretty dangerous to me -- you'll end up with aliases to the
same buffer this way if user space isn't careful.

I bet you check duplicate buffer usage by pointer and not ID though,
which means user space will get errors when this happens. That's not
terrible, but it isn't great either as there's this nasty call to
exit(1) when the execbuffers fails...

> Otoh this can't hurt either, so if you want to stick with this hunk maybe
> add a small comment saying that the kernel lies. Or just remove it. Either
> way:

Not being able to test it is a bit sub-optimal; the duplicate handle
case for prime was well tested by the time I submitted that patch...

> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>

thanks.

> Aside: I think drm is the only subsystem that goes out of it's way to
> ensure a unique relationship between dmabuf and other handles and
> underlying objects. If you throw v4l into the mix (e.g. by building a
> gstreamer pipe that feeds into an egl image or so) I expect some fun to
> happen. Otoh no open-source v4l driver for intel socs, so lalala ;-)

Some kind of standard of conduct is clearly needed here - not letting
user space know they've got aliasing going on is pretty mean.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131126/5e8e2da0/attachment.pgp>