Messages in this thread | | | Date | Wed, 14 Jul 2004 07:26:14 -0700 | From | Greg KH <> | Subject | Re: [RFC] Refcounting of objects part of a lockfree collection |
| |
On Wed, Jul 14, 2004 at 01:56:22PM +0530, Dipankar Sarma wrote: > On Wed, Jul 14, 2004 at 12:07:00AM -0700, Greg KH wrote: > > On Wed, Jul 14, 2004 at 10:23:50AM +0530, Ravikiran G Thirumalai wrote: > > > > > > The attatched patch provides infrastructure for refcounting of objects > > > in a rcu protected collection. > > > > This is really close to the kref implementation. Why not just use that > > instead? > > Well, the kref has the same get/put race if used in a lock-free > look-up. When you do a kref_get() it is assumed that another > cpu will not see a 1-to-0 transition of the reference count.
You mean kref_put(), right?
> If that indeed happens, ->release() will get invoked more > than once for that object which is bad.
As kref_put() uses a atomic_t, how can that transistion happen twice?
What can happen is kref_get() and kref_put() can race if the last kref_put() happens at the same time that kref_get(). But that is solved by having the caller guarantee that this can not happen (see my 2004 OLS paper for more info about this.)
> Kiran's patch actually solves this fundamental lock-free ref-counting > problem.
Hm, maybe I'm missing something, but I don't see how it does so, based on the implmentation of refcount_get() and refcount_put(). Sure, the *_rcu implementations are a bit different, but if that's the only difference with this code and kref, why not just add the rcu versions to the kref code?
> The other issue is that there are many refcounted data structures > like dentry, dst_entry, file etc. that do not use kref.
At this time, sure. But you could always change that :) (and yes, to do so, we can always shrink the size of struct kref if really needed...)
> If everybody were to use kref, we could possibly apply Kiran's > lock-free extensions to kref itself and be done with it.
Ok, sounds like a plan to me. Having 2 refcount implementations in the kernel that work alike, yet a bit different, is not acceptable. Please rework struct kref to do this.
> Until then, we need the lock-free refcounting support from non-kref > refcounting objects.
We've lived without it until now somehow :)
thanks,
greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |