From mboxrd@z Thu Jan 1 00:00:00 1970 From: Imre Deak Subject: Re: [PATCH 2/2] drm: prime: fix lookup of existing imports for self imported buffers Date: Thu, 11 Apr 2013 12:24:55 +0300 Message-ID: <1365672295.2476.3.camel@intelbox> References: <1365509289-11796-1-git-send-email-imre.deak@intel.com> <1365509289-11796-2-git-send-email-imre.deak@intel.com> Reply-To: imre.deak@intel.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Dave Airlie Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Wed, 2013-04-10 at 07:52 +1000, Dave Airlie wrote: > > Since atm we don't take a reference on the dma buf pointer when we add > > it to the import lookup table the dma buf can vanish leaving the stale > > pointer behind. This can in turn lead to returning stale GEM handles > > when userspace imports a newly exported buffer. > > > I sent a bunch of patches to prime months ago, maybe go back and dig them out > > they might fix some of these issues, > > I think danvet bikeshedded my will to care at the time due to lack of > proper locking, > the fact is the patches didn't change the locking, but I could > probably go back and find them. > > Hopefully you haven't gone and reinvented that work. Yes, I checked it with the i-g-t/prime_self_import test case and it's passing with your "drm/prime: keep a reference from the handle to exported dma-buf (v2.1)" patch, so we can drop this one. --Imre