On Fri, 2005-04-01 at 00:48 -0800, Andrew Morton wrote: > Evgeniy Polyakov <[email protected]> wrote: > > > > New object has 0 reference counter when created. > > If some work is appointed to the object, then it's counter is atomically > > incremented. It is decremented when the work is finished. > > If object is supposed to be removed while some work > > may be appointed to it, core ensures that no work _is_ appointed, > > and atomically disallows[for example removing workqueue, removing > > callback, all with appropriate locks being hold] > > any other work appointment for the given object. > > After it [when no work can be appointed to the object] if object > > still has pending work [and thus has it's refcounter not zero], > > removing path waits untill appropriate refcnt hits zero. > > Since no _new_ work can be appointed at that level it is just > > while (atomic_read(refcnt) != 0) > > msleep(); > > More like: > > while (atomic_read(&obj->refcnt)) > msleep(); > kfree(obj); Yep :) > which introduces the possibility of someone grabbing a new ref on the > object just before the kfree(). If there is no means by which any other > actor can acquire a ref to this object then OK, no race. No, object is already removed from the pathes where someone may access it. It is only waiting until already assigned work is finished. > But it's rather surprising that such a thing can be achieved without any > locking. What happens if another CPU has just entered > cn_queue_del_callback(), for example? It has a live cn_callback_entry in > `cbq' which has a zero refcount - cn_queue_free_dev() can throw it away. cn_queue_free_dev() will wait until dev->refcnt hits zero before freeing any resources, but it can happen only after cn_queue_del_callback() does it's work on given callback device [actually when all callbacks are removed]. When new callback is added into device, it's refcnt is incremented [before adition btw, if addition fails in the middle, reference is decremented], when callbak is removed, device's reference counter is decremented aromically after all work is finished. -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Attachment:
signature.asc
Description: This is a digitally signed message part
- Follow-Ups:
- Re: cn_queue.c
- From: Andrew Morton <[email protected]>
- Re: cn_queue.c
- References:
- cn_queue.c
- From: Andrew Morton <[email protected]>
- Re: cn_queue.c
- From: Evgeniy Polyakov <[email protected]>
- Re: cn_queue.c
- From: Andrew Morton <[email protected]>
- Re: cn_queue.c
- From: Evgeniy Polyakov <[email protected]>
- Re: cn_queue.c
- From: Andrew Morton <[email protected]>
- cn_queue.c
- Prev by Date: Re: [1/1] CBUS: new very fast (for insert operations) message bus based on kenel connector.
- Next by Date: Re: Industry db benchmark result on recent 2.6 kernels
- Previous by thread: Re: cn_queue.c
- Next by thread: Re: cn_queue.c
- Index(es):