Daniel Vetter <daniel@xxxxxxxx> 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@xxxxxxxx> 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@xxxxxxxxx
Attachment:
pgpdSrgdSuVNp.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
