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: [PING][PATCH][BZ #15073] Fix race in free.


On Mon, Dec 23, 2013 at 10:01:47AM +1300, Maxim Kuvyrkov wrote:
> On 22/12/2013, at 10:07 am, OndÅej BÃlka <neleai@seznam.cz> 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 <neleai@seznam.cz> 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 :-)?
> 
If you think that this is useful you can keep that and proceed with your
patch.


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