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@xxxxxxxx Mobile: +41 (0)79 365 57 48 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
