From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Hellstrom <thellstrom@vmware.com>
Subject: Re: buggy/weird behavior in ttm
Date: Mon, 15 Oct 2012 14:14:51 +0200
Message-ID: <507BFE3B.5070504@vmware.com>
References: <5076DCAD.6070606@canonical.com> <5076FA78.9090507@vmware.com>
	<50771307.3080807@canonical.com> <50771D50.5000104@vmware.com>
	<50773251.9060205@canonical.com> <5077B15D.6090509@vmware.com>
	<5077CBA7.2050509@canonical.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 E0E7F9E78D
	for <dri-devel@lists.freedesktop.org>;
	Mon, 15 Oct 2012 05:14:54 -0700 (PDT)
In-Reply-To: <5077CBA7.2050509@canonical.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/12/2012 09:49 AM, Maarten Lankhorst wrote:
>
>>>>> I suppose there will stay a small race though,
>>>> Hmm, where?
>>> When you enter the ddestroy path, you drop the lock and hope the buffer doesn't reserved
>>> away from under you.
>> Yes, that code isn't fully correct, it's missing a check for still on ddestroy after a waiting
>> reserve. However, the only chance of a waiting reserve given that the buffer *IS* on the
>> ddestroy list is if the current reserver returned early because someone started an
>> accelerated eviction which can't happen currently. The code needs fixing up though.
> bo gets put on ddestroy list, delayed destroy handler gets reservation and we try to get a
> reservation at the same time in ttm_mem_evict_first, losing out.
>
> Unlikely? Yes, but I don't see how it is impossible.

Anyone getting the reservation will remove the buffer from the ddestroy 
list atomically,
That means that another caller that finds the buffer on the ddestroy 
list will get the
reservation without wait. The exeption is if *anyone* gets the 
reservation without
removing it from the ddestroy list. That would trigger catastrophic 
failure, but I don't
think that's possible with the current code.

So yes, the code is broken, but I don't think it breaks anything currently.

/Thomas