public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Damien Lespiau <damien.lespiau@intel.com>
To: "Chris Wilson" <chris@chris-wilson.co.uk>,
	"Michał Winiarski" <michal.winiarski@intel.com>,
	intel-gfx@lists.freedesktop.org,
	"Rafał Sapała" <rafal.a.sapala@intel.com>
Subject: Re: [PATCH libdrm] intel: Serialize drmPrimeFDToHandle with struct_mutex
Date: Fri, 21 Aug 2015 14:46:24 +0100	[thread overview]
Message-ID: <20150821134624.GD5032@strange.ger.corp.intel.com> (raw)
In-Reply-To: <20150724105101.GV6166@nuc-i3427.alporthouse.com>

On Fri, Jul 24, 2015 at 11:51:01AM +0100, Chris Wilson wrote:
> On Fri, Jul 24, 2015 at 11:22:34AM +0200, Michał Winiarski wrote:
> > From: Rafał Sapała <rafal.a.sapala@intel.com>
> > 
> > It is possible to hit a race condition in create_from_prime, when trying
> > to import a BO that's currently being freed. In case of prime sharing
> > we'll succesfully get a handle, but fail on get_tiling call, potentially
> > confusing the caller (and requiring different locking scheme than with
> > sharing using flink). Wrap fd_to_handle with struct_mutex to force
> > a more consistent behaviour between prime/flink, convert fprintf to DBG
> > when handling errors.
> 
> The race is that the kernel returns us the same file-private handle as
> the first thread, but that first thread is about to call gem_close
> (thereby removing the handle from the file completely) and does so
> between us acquiring the handle and taking the mutex. If we take
> the mutex, then we acquire the refcnt on the bo prior to the first
> thread completing its unref (and so preventing the early close). Or we
> acquire the handle after the earlier close, in which case we are the new
> owner.
> 
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

Thanks for the patch & review, pushed.

-- 
Damien
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

      reply	other threads:[~2015-08-21 13:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-24  9:22 [PATCH libdrm] intel: Serialize drmPrimeFDToHandle with struct_mutex Michał Winiarski
2015-07-24  9:24 ` [PATCH i-g-t] tests/drm_import_export: Add tests for prime/flink sharing races Michał Winiarski
2015-07-24 13:28   ` Thomas Wood
2015-07-24 14:43   ` [PATCH i-g-t v2] " Michał Winiarski
2015-07-24 14:57     ` Thomas Wood
2015-07-24 10:51 ` [PATCH libdrm] intel: Serialize drmPrimeFDToHandle with struct_mutex Chris Wilson
2015-08-21 13:46   ` Damien Lespiau [this message]

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=20150821134624.GD5032@strange.ger.corp.intel.com \
    --to=damien.lespiau@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=michal.winiarski@intel.com \
    --cc=rafal.a.sapala@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox