From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH] drm: Replace kref with a simple atomic reference count Date: Sun, 28 Nov 2010 14:35:26 +0100 Message-ID: <20101128133525.GA3710@viiv.ffwll.ch> References: <1290721205-32433-1-git-send-email-chris@chris-wilson.co.uk> <1290724709.5661.54.camel@clockmaker-el6> <4CF24BDB.2000204@shipmail.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail.ffwll.ch (cable-static-49-187.intergga.ch [157.161.49.187]) by gabe.freedesktop.org (Postfix) with ESMTP id C3F399E732 for ; Sun, 28 Nov 2010 05:35:33 -0800 (PST) Content-Disposition: inline In-Reply-To: <4CF24BDB.2000204@shipmail.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: Thomas Hellstrom Cc: Dave Airlie , dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Sun, Nov 28, 2010 at 01:32:27PM +0100, Thomas Hellstrom wrote: > 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. I've got curious rechecked the code and it all looks sane. The trick is that all the userspace-visible names hold a ref to the underlying gem object (including the flink name). If all userspace handles are destroyed (save the flink name) the flink name gets destroyed, too (see obj->handle_count). All this is independently protected with spinlocks and it happens _before_ dropping the ref to the underlying bo (and taking any necessary locks to do so). I don't see any races nor locking problems, there. -Daniel -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48