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: BZ 13939 malloc deadlock


On 3/07/2012, at 9:21 AM, Jeff Law wrote:

> On 07/02/2012 02:00 PM, Maxim Kuvyrkov wrote:
>> 
>> I don't recommend going this way as it is error-prone for bugs from
>> future changes.  A reasonable programmer would expect ar_ptr->mutex
>> to lock the entirety of ar_ptr, including ar_ptr->next.
> Precisely.  Thus if we're trying to be robust WRT future changes and avoiding problems with ar->next changing after the lock is released but before we call arena_get2 (which is what it looks like libc_memalign is trying to do), then we need to get the value from ar->next before we release the lock.
> 
> Note that libc_malloc and libc_calloc's current implementations can't race on ar->next because the lock is still held.  Of course it's the holding of that lock which leads to the deadlock that we're trying to fix right now.
> 
> libc_pvalloc and libc_valloc's current implementation would have problems if there are races with writes to ar->next as they unlock the arena then blindly use the current value of ar->next.

I see now, you are right again.  I would appreciate you adding a comment to one of the instances of "prev = ar_ptr->next" saying something like "Get ar_ptr->next before releasing the lock.".

Thanks,

--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics


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