On Mon, Jan 11, 2016 at 08:44:03PM +0000, Chris Wilson wrote: > On Mon, Jan 11, 2016 at 07:51:03PM +0200, Ville Syrjälä wrote: > > On Fri, Jan 08, 2016 at 11:27:05PM +0000, Chris Wilson wrote: > > > When userspace closes a handle, we remove it from the file->object_idr > > > and then tell the driver to drop its references to that file/handle. > > > However, as the file/handle is already available again for reuse, it may > > > be reallocated back to userspace and active on a new object before the > > > driver has had a chance to drop the old file/handle references. > > > > Hmm. What's the problem with another object starting to reuse the same > > handle while we're still deleting the old one? So far I didn't spot > > anything in the code that would go boom if there's another object > > already around with the same handle. > > Imagine a driver storing a hashtable to contract the handle->object->vma > lookup into just handle->vma, like the old idea of replacing the > object_idr with an ida plus hashtable of objects. (This saves the double > step lookup that caused a regression with the ppgtt work, and the linear > walk of object->vma_list which is a major slowdown in various full-pggtt > OpenGL tests). In such a scheme, where the driver has a parallel lut to > the core, the driver needs to be notified before the handle is then > accessible again to userspace. Or in any other scenario where the driver > is using the handle, as would be implied by having the open/close > callbacks. I see. Yeah, that makes sense. I was just a bit confused since I couldn't find any real problem in the tree currently. -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
