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

[Ondřej Bílka]

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.