From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Packard Subject: Re: [PATCH] intel: Track known prime buffers for re-use Date: Tue, 26 Nov 2013 03:40:31 -0800 Message-ID: <86wqjvfl1s.fsf@miki.keithp.com> References: <86eh645g9l.fsf@miki.keithp.com> <1385414561-29043-1-git-send-email-keithp@keithp.com> <20131126094241.GK27344@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0063835612==" Return-path: In-Reply-To: <20131126094241.GK27344@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: Daniel Vetter Cc: mesa-dev@lists.freedesktop.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0063835612== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Daniel Vetter 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 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. =2D-=20 keith.packard@intel.com --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIVAwUBUpSIr9siGmkAAAARAQgXnQ//SlwP0/wny6gZP/wuMo86RF2v36azHyNI Dfln8Hsit8GmGrIOS8K4QbxaSg9Hakg9gpjOVKUSJNEQZceDn8yJiPWAVThimYZc qWOx0CmAQqLSa5QceT68zMreFmNDCVggj+ynEgAmU3BFxgf0YWx/dUQpTvFqYmvf kb1Rj3EhdO/DA/pJYbPAB5Xe1jBqBchT+pf3nTpY8NezT06zdZ8UR7yIUKOQMXpx 927ffEgjs5B+9ozb1tu/ZvQi0UX+QsbySSXJxFixvEAVw9Ey0c3k8cb3ri3Zo3wn nBBQhIXqwr/qpwwcgGCa+ov+OrrUnFy6OHgrtzJ9EwOMZf8ariD7U6mnFLSXJccx VtBCZAMjMhp/vJvc6vEUGmQI3QvQzrkhaYibUYyLYNSt2Y2V5bHcLlDjHe0VfWTI P+IMcw7owiumvhwZgDrkTwZppUXwm63xbqaKy2ZhNY8RJVefhgiUdRd9g7fIdF1Y cwwrnygij4OZzgDzWRKVfuVzdpS7oYIgRgNqVbMNVzi3mqhFTRKysAtfsxxybiTM frt7yP8WT8FI9wimbp9qTJsA19UIJ+TMuBO+GpluNYCeMGaEtKwkoH41gax9+cTS 2hj7Vs4lKnngUUSmASphZc41Sjtivph4UxW3Oh1HIUkNTnVkGReKsZhCbtZwXqJx PDlaiYZYMBs= =UtiB -----END PGP SIGNATURE----- --=-=-=-- --===============0063835612== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============0063835612==--