This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PING][PATCH][BZ #15073] Fix race in free.


On Thu, Dec 19, 2013 at 07:35:25PM -0500, Nate Gallaher wrote:
>    I am not sure that is a complete solution.  I believe that any fastbin
>    content dereference is a potential race point.
> 
>    For example, in _int_malloc:
>    3268     mfastbinptr* fb = &fastbin (av, idx);
>    3269     mchunkptr pp = *fb;
>    3270     do
>    3271       {
>    3272         victim = pp;
>    3273         if (victim == NULL)
>    3274           break;
>    3275       }
>    3276     while ((pp = catomic_compare_and_exchange_val_acq (fb,
>    victim->fd, victim))
>    3277            != victim);
> 
>    If we assume that there are entries in the fastbin (so pp is non-NULL),
>    and the following happens:
> 
>    Thread #1:
>     * Executes lines 3268 through 3274.  pp and victim are non-NULL.
>    Context swap to Thread #2:
>     * Executes code that frees enough memory into the fastbin to trigger the
>    bin consolidation.
>     * Bin consolidation frees the page that pp and victim pointed into using
>    systrim().  This page is returned to the system.
>    Context swap to Thread #1:
>     * In setting up for the compare and swap on line 3276, we dereference
>    victim to get victim->fd.  Since victim points to memory that was released
>    to the system, we get a segfault.
>    Is my understanding correct?
> 
No, malloc is protected by lock (arena_lock/arena_get macros from __libc_malloc/memalign).

Yes, its ineffective which I try to solve by per thread-cache where no
locking on fast path is necessary.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]