From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Hellstrom <thellstrom@vmware.com>
Subject: Re: buggy/weird behavior in ttm
Date: Thu, 11 Oct 2012 21:35:43 +0200
Message-ID: <50771F8F.7080403@vmware.com>
References: <5076DCAD.6070606@canonical.com> <5076FA78.9090507@vmware.com>
	<50771307.3080807@canonical.com> <50771D50.5000104@vmware.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org>
Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com
	[208.91.2.12])
	by gabe.freedesktop.org (Postfix) with ESMTP id 2B0629E81C
	for <dri-devel@lists.freedesktop.org>;
	Thu, 11 Oct 2012 12:35:47 -0700 (PDT)
In-Reply-To: <50771D50.5000104@vmware.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/dri-devel>,
	<mailto:dri-devel-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/dri-devel>
List-Post: <mailto:dri-devel@lists.freedesktop.org>
List-Help: <mailto:dri-devel-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/dri-devel>,
	<mailto:dri-devel-request@lists.freedesktop.org?subject=subscribe>
Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
To: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org

On 10/11/2012 09:26 PM, Thomas Hellstrom wrote:
> On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:

> I can't see how the waiting reserve in ttm_bo_cleanup_refs would cause 
> a deadlock,
> because the buffer about to be reserved is always *last* in a 
> reservation sequence, and the
> reservation is always released (or the buffer destroyed) before trying 
> to reserve another buffer.
> Technically the buffer is not looked up from a LRU list but from the 
> delayed delete list.
> Could you describe such a deadlock case?
> (There is a bug in there, though that the reservation is not released 
> if the buffer is no longer
> on the reservation list here):
>
> if (unlikely(ret != 0) || list_empty(&bo->ddestroy)) {
>      spin_unlock(&glob->lru_lock);
>      return ret;
> }

Actually I was looking at older code. That bug is already fixed.

/Thomas