This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3] malloc: Fix list_lock/arena lock deadlock [BZ #19182]
- From: Florian Weimer <fweimer at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 17 Dec 2015 20:18:15 +0100
- Subject: Re: [PATCH v3] malloc: Fix list_lock/arena lock deadlock [BZ #19182]
- Authentication-results: sourceware.org; auth=none
- References: <567003D1 dot 40203 at redhat dot com> <1450379123 dot 26597 dot 10 dot camel at localhost dot localdomain>
On 12/17/2015 08:05 PM, Torvald Riegel wrote:
>> + (void) mutex_lock (&free_list_lock);
>> + detach_arena (replaced_arena);
>> + (void) mutex_unlock (&free_list_lock);
>> +
>> + /* Lock this arena. NB: We may not have exclusive access to this
>> + arena anymore because the arena is now accessible from the
>> + main_arena.next list and could have been picked by reused_arena
>> + in the meantime. This can only happen for the last arena created
>> + (before the arena limit is reached). This seems unlikely, so we
>> + do not protect against this special case. */
>
> "This seems unlikely" is not sufficient for correctness, IMO.
Just one quick comment: It's not a correctness issue. I will clarify
that the new arena can be attached to multiple threads (not a problem
because there is proper locking, it's just a surprising aspect we should
document).
Florian