This is the mail archive of the
mailing list for the glibc project.
Re: [patch] Fix BZ#16374 -- don't use mmap for FILE buffers
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Paul Pluzhnikov <ppluzhnikov at google dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Mon, 16 Feb 2015 14:04:08 -0500
- Subject: Re: [patch] Fix BZ#16374 -- don't use mmap for FILE buffers
- Authentication-results: sourceware.org; auth=none
- References: <CALoOobNomWyxd9Oz3=kHq0vyBpmfxSyj_cFBxyahCJSs1cZBzQ at mail dot gmail dot com> <54E236D9 dot 3010807 at redhat dot com> <CALoOobPVr0PAkzDtQbXXGP7Vyu-Ls+V-1JGXpi8yBbyryqYf5g at mail dot gmail dot com>
On 02/16/2015 01:51 PM, Paul Pluzhnikov wrote:
> On Mon, Feb 16, 2015 at 10:28 AM, Carlos O'Donell <email@example.com> wrote:
>> This patch is not OK as-is, and needs to be split into multiple patches.
>> One patch for the calloc/free changes, and another with much much much
>> more detail for the semantic changes that fix input-only unclean buffers.
> The first patch will break 3 (mtrace) tests, and the second will then
> fix them. Is that ok?
Yes, post them as 0/2 (descriptions), 1/2 (conversion), and 2/2 (bug fix).
> On Mon, Feb 16, 2015 at 10:32 AM, Florian Weimer <firstname.lastname@example.org> wrote:
>>> Attached patch replaces mmap()s with calloc()s.
>> Why is calloc needed?
> In previous discussion it was mentioned that something was expecting
> the buffers to be zero'ed out, but you are right -- fallback used
> malloc and calloc shouldn't be necessary (this should nicely speed
> things up on systems with large pages :)
> I've retested with s/calloc/malloc/ and found no failures.