All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
	Thierry Reding <treding@nvidia.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2] drm: Release driver references to handle before making it available again
Date: Mon, 11 Jan 2016 20:44:03 +0000	[thread overview]
Message-ID: <20160111204403.GN652@nuc-i3427.alporthouse.com> (raw)
In-Reply-To: <20160111175103.GI23290@intel.com>

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.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2016-01-11 20:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-08 20:25 [PATCH] drm: Release driver references to handle before making it available again Chris Wilson
2016-01-08 23:19 ` Chris Wilson
2016-01-08 23:27 ` [PATCH v2] " Chris Wilson
2016-01-11 17:51   ` Ville Syrjälä
2016-01-11 20:44     ` Chris Wilson [this message]
2016-01-12 10:17       ` Ville Syrjälä
2016-01-12 10:19   ` Ville Syrjälä
2016-01-12 10:54     ` Chris Wilson
2016-01-11 10:53 ` ✗ warning: Fi.CI.BAT Patchwork
2016-01-11 10:55 ` Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160111204403.GN652@nuc-i3427.alporthouse.com \
    --to=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=treding@nvidia.com \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.