lkml.org 
[lkml]   [2005]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: cn_queue.c
Evgeniy Polyakov <johnpol@2ka.mipt.ru> 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);

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.

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.

-
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/

\
 
 \ /
  Last update: 2005-04-06 13:31    [W:0.382 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site