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: Torvald Riegel <triegel at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 17 Dec 2015 20:28:22 +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> <56730A77 dot 7050800 at redhat dot com>
On Thu, 2015-12-17 at 20:18 +0100, Florian Weimer wrote:
> 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).
OK. Pointing out that this is just a relevant for performance and not a
correctness issue would be good.