Re: [PATCH 08/17] drm/i915: Drop spinlocks around adding to the client request list

From: John Harrison <John.C.Harrison@Intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 08/17] drm/i915: Drop spinlocks around adding to the client request list
Date: Fri, 2 Sep 2016 14:20:16 +0100	[thread overview]
Message-ID: <8c184d3d-2143-de8c-a095-38f8647c50e6@Intel.com> (raw)
In-Reply-To: <20160902110239.GA16031@nuc-i3427.alporthouse.com>

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?

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