From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Hellstrom <thomas@shipmail.org>
Subject: Re: [PATCH] drm: Replace kref with a simple atomic reference count
Date: Sun, 28 Nov 2010 13:32:27 +0100
Message-ID: <4CF24BDB.2000204@shipmail.org>
References: <1290721205-32433-1-git-send-email-chris@chris-wilson.co.uk>
	<1290724709.5661.54.camel@clockmaker-el6>
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-2.vmware.com (smtp-outbound-2.vmware.com
	[65.115.85.73])
	by gabe.freedesktop.org (Postfix) with ESMTP id B0E349E730
	for <dri-devel@lists.freedesktop.org>;
	Sun, 28 Nov 2010 04:32:47 -0800 (PST)
In-Reply-To: <1290724709.5661.54.camel@clockmaker-el6>
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: Dave Airlie <airlied@redhat.com>
Cc: dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org

On 11/25/2010 11:38 PM, Dave Airlie wrote:
> On Thu, 2010-11-25 at 21:40 +0000, Chris Wilson wrote:
>    
>> For a deferred-free cache of unreferenced bound objects, a simple
>> reference count is required without the baggage of kref.
>>      
> eh?
>
> you've just out of lined kref for no real gain.
>
> the whole point of kref is that its standard and doesn't require
> auditing for the people not inlining it.
>
> The only place I can see the advantage is not taking the struct mutex in
> the free path and really we should just fix the free function to take
> the struct mutex if required and wrap the real free.
>
>    
This last thing is really a generic problem with objects looked up from 
user-space. Consider the lookup path:

read_lock()
lookup_object_name();
kref_get();
read_unlock();

And the destroy path:

vs the desired put path
if (reference_put()) {
write_lock():
remove_name();
write_unlock();
destroy();
}

This is racy, in that the kref_get() can hit a zero refcount. I think an 
ideal thing here would be to add a kref_get_unless_zero() for this 
situation, that returns an error if the refcount was indeed zero. I 
don't think that would violate the kref idea, since we still never 
increase the refcount of a zeroed object, and the user needs to provide 
the necessary synchronization to make sure the object isn't gone while 
still the refcount is zero.

/Thomas






> Dave.
>
>