httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Seg fault: Possible race conditions in mod_mem_cache.c
Date Wed, 08 Sep 2004 19:44:29 GMT
oops, didn't mean to send it privately

---------- Forwarded message ----------
From: Jeff Trawick <trawick@gmail.com>
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 <jjclar@novell.com>

On Wed, 08 Sep 2004 12:38:38 -0600, Jean-Jacques Clar <jjclar@novell.com> 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.

Mime
View raw message