Re: [PATCH] [RFC] malloc: Reduce worst-case behaviour with madvise and refault overhead

[Florian Weimer <fweimer at redhat dot com>]

On 02/10/2015 03:56 PM, Carlos O'Donell wrote:
> On 02/10/2015 07:30 AM, Florian Weimer wrote:
>> On 02/09/2015 09:52 PM, Carlos O'Donell wrote:
>>> On 02/09/2015 09:06 AM, Mel Gorman wrote:
>>>> while (data_to_process) {
>>>> 	buf = malloc(large_size);
>>>> 	do_stuff();
>>>> 	free(buf);
>>>> }
>>>
>>> Why isn't the fix to change the application to hoist the
>>> malloc out of the loop?
>>
>> For a lot of C++ code, this would require replacing global operator new
>> with a pool allocator.  We do not want programmers to do that, for
>> various reasons (loss of tooling, our limited malloc hardening, etc.).
>  
> Is this because the objects are implicitly allocated by the language
> in the inner loop using new?

Not by the language, but by libraries.  The libraries may not offer a
choice to avoid the large allocation and deallocation.  In general,
object reuse is no longer considered good design because it typically
complicates the different states an object must support.  This is
probably not specific to C++, it may affect modern C code as well (which
tends to hide implementation details with pointers to incomplete structs
etc., and not rely on callers providing sufficiently sized buffers).

Even if there is a way to reuse objects (e.g., we have freopen in
addition to fopen/close), I don't want to suggest it to developers
because it eventually leads to custom allocators, pools and the problems
that come with them.

-- 
Florian Weimer / Red Hat Product Security