Re: [PATCH libdrm] intel: Serialize drmPrimeFDToHandle with struct_mutex

From: Chris Wilson <chris@chris-wilson.co.uk>
To: "Michał Winiarski" <michal.winiarski@intel.com>
Cc: 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, 24 Jul 2015 11:51:01 +0100	[thread overview]
Message-ID: <20150724105101.GV6166@nuc-i3427.alporthouse.com> (raw)
In-Reply-To: <1437729754-8683-1-git-send-email-michal.winiarski@intel.com>

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

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