[Intel-gfx] [PATCH 08/17] drm/i915: Drop spinlocks around adding to the client request list
John Harrison
John.C.Harrison at Intel.com
Fri Sep 2 13:20:16 UTC 2016
On 02/09/2016 12:02, Chris Wilson wrote:
> On Fri, Sep 02, 2016 at 11:59:12AM +0100, Chris Wilson wrote:
>> On Fri, Sep 02, 2016 at 11:30:18AM +0100, John Harrison wrote:
>>>> + if (request->file_priv) {
>>> Why check for request->file_priv again? The block above will exit if
>>> it is null. There surely can't be a race with remove_from_client
>>> being called concurrently with add_to_client? Especially as
>>> add_to_client no longer takes the spin_lock anyway.
>> We can however allow i915_gem_release() to be called concurrently. It
>> doesn't require struct_mutex.
> That's not correct. setting file_priv = NULL is serialised by the
> struct_mutex, not the file_priv->mm.lock. That spin_lock there is
> misleading.
> -Chris
>
The spinlock is to protect the list rather than the request, I thought.
AFAICS, i915_gem_release() is only called from i915_driver_preclose()
and that holds the mutex lock. So you are safe?
More information about the Intel-gfx
mailing list