This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [Patch] Fix another unbound alloca (BZ 13761)
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: "Carlos O'Donell" <carlos_odonell at mentor dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Mon, 2 Jul 2012 15:02:55 -0700 (PDT)
- Subject: Re: [Patch] Fix another unbound alloca (BZ 13761)
- References: <4FE4D9C3.70703@redhat.com><4FE4DAE8.3060700@mentor.com><4FE4E44A.6090308@redhat.com><20120622221446.21BC32C08D@topped-with-meat.com><4FF2166C.3010207@redhat.com>
> It seems to me that freeing dataset is just wrong if it's allocated via
> mempool_alloc and things in mempool_alloc are GC'd.
Correct.
> ISTM the safe thing to do would be something like:
>
> if (he == NULL)
> dataset = (struct dataset *) mempool_alloc (db, total + n, 1);
> else if (! __libc_use_alloca (alloca_used + total + n))
> dataset = (struct dataset *) malloc (...);
Agreed. Note that in the existing code ALLOCA_USED is a Boolean, and it is
used to mean "cannot be placed in the cache". So the bookkeeping would
change somewhat to support the malloc case (which is alloca_used=true in
the current sense of that variable, but also has to be freed).
> While it might be safe/appropriate to use mempools in the case where the
> needed space is large and transient, it's hard to prove.
The purpose of the mempool stuff is to use the shared memory space that's
available to clients as a cache without interacting with nscd. So it's
never appropriate for something that is not going to be looked up in that
cache later.
Thanks,
Roland