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.