[PATCH v2] drm: Release driver references to handle before making it available again
Ville Syrjälä
ville.syrjala at linux.intel.com
Tue Jan 12 02:17:09 PST 2016
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
More information about the dri-devel
mailing list