This is the mail archive of the
mailing list for the glibc project.
Re: [PING][PATCH][BZ #15073] Fix race in free.
- From: Maxim Kuvyrkov <maxim at kugelworks dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Mon, 23 Dec 2013 10:01:47 +1300
- Subject: Re: [PING][PATCH][BZ #15073] Fix race in free.
- Authentication-results: sourceware.org; auth=none
- References: <20131210194349 dot GA19644 at domone dot podge> <20131218102757 dot GC6559 at domone dot podge> <C593C68D-FF0C-4C46-93E2-4A3ABA33E84B at kugelworks dot com> <20131221205921 dot GA3549 at domone dot podge>
On 22/12/2013, at 10:07 am, OndÅej BÃlka <email@example.com> wrote:
> On Sun, Dec 22, 2013 at 09:08:42AM +1300, Maxim Kuvyrkov wrote:
>> On 18/12/2013, at 11:27 pm, OndÅej BÃlka <firstname.lastname@example.org> wrote:
>>>> Solution is simply drop that check.
>> Or fix the check. If we have_lock for the memory state there is no way a competing thread can snatch and deallocate the fastbin chunk that we are adding to.
> As most malloc checks decrease readibility I favor deletion. Adding a
> check for lock solves problem but as _int_free always called from
> __libc_free with have_lock = 0 it would render check mostly useless.
I do not quite agree with this. Sanity checks like the one in question tend to expose arcane bugs, and, given that it is very lightweight (no function calls, just several macros doing bit math), I prefer to keep it. It is true that primary use from __libc_free will not benefit from the sanity check, but there are quite a few uses with have_lock==1.
I do not think that we should dwell for too much longer on whether remove or keep the check, as our time is best spent fixing other bugs in glibc. If you really feel strongly about removing the check, how about rock-paper-scissors on IRC :-)?