oops, didn't mean to send it privately ---------- Forwarded message ---------- From: Jeff Trawick <[EMAIL PROTECTED]> Date: Wed, 8 Sep 2004 15:43:35 -0400 Subject: Re: Seg fault: Possible race conditions in mod_mem_cache.c To: Jean-Jacques Clar <[EMAIL PROTECTED]>
On Wed, 08 Sep 2004 12:38:38 -0600, Jean-Jacques Clar <[EMAIL PROTECTED]> wrote: > > >I find the possible need for the patch very disturbing; it implies to > >me a problem in the atomics code > > I don't know. > I had the NetWare dec code reviewed by the people who > wrote/maintain our kernel, this is why I changed the > apr_atomic_dec(), and from what I understand the > problem should be ours. well, I'm using portable atomics anyway on SLES8/PPC, and those are as simple as possible, so I should shut up about atomics being broken ;) something about the overall design is odd; you said before: >Both threads are working on the same cache_object. >Refcount is 1, obj->cleanup is 0 when entering decrement_refcount(). That's bad already. At any time when there are n threads with a "handle" to a cache object, refcount ought to be n in order to be able to free it when refcount goes to zero. Unless: Condition 1) a mutex is held between the time that a thread gets a handle to the cache object and when the thread increments the refcount to reserve its handle *AND* Condition 2) Logic like that in decrement_refcount() which checks for refcount == 0 holds the very same mutex when it decrements and checks for refcount == 0, in order to insure that there are no other threads which are holding the mutex and are about to increment refcount. Is condition 1 already met by the design of the cache/refcount? Condition 2 is then satisfied by your latest patch.
