Re: [PATCH][RFC] Allow explicit shrinking of arena heaps using anenvironment variable

[Carlos O'Donell <carlos_odonell at mentor dot com>]

On 7/20/2012 3:51 PM, Siddhesh Poyarekar wrote:
> On Fri, 20 Jul 2012 14:45:36 -0400, Carlos wrote:
>> On 7/20/2012 6:55 AM, Siddhesh Poyarekar wrote:
>>> kernel that we don't want to use that part. For setuid programs, we
>>> go a step further and ensure that the consolidated region to be
>>> freed has no permissions, by calling mmap() on it with MAP_FIXED
>>> and PROT_NONE.
>>
>> Why do we do this for setuid programs? It isn't immediately obvious
>> to me why it should matter.
> 
> There are two things that the mmap does and I suspect that it's the
> second one that matters more:
> 
> 1. Makes the freed mapping PROT_NONE, thus preventing access to that
>    region
> 2. Discard the contents in that region, so that it cannot be read even
>    by manually reverting the protection. Of course, there's no
>    preloading available to inject such code, but even if there was a
>    way to inject code, at least that memory would no longer be readable.

OK, this makes more sense. I can see (2) being useful for setuid programs.
 
>>> The default behaviour remains as before -- this new behaviour is
>>> only seen when MALLOC_ARENA_SHRINK is exported and set to a
>>> positive value.
>>
>> Why don't we enable this unconditionally?
>>
>> What would be the problem in doing that?
> 
> mmap is more expensive than madvise, with the zeroing of pages and all
> that, so it might not be the best option to enable unconditionally. I
> wonder what the performance improvement will be with doing a
> memset(..., 0, ...) on the tail of the arena and then calling mprotect
> instead of the mmap.

OK, so there is a performance implication. The normal use case doesn't
require (2) as defined above.

What is your use case for this new feature?

You've explained already why you want it, but what problem does it
solve for you, other than being a poor API for exposing how much of
the arena is in use?

Cheers,
Carlos.
-- 
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos_odonell@mentor.com
carlos@codesourcery.com
+1 (613) 963 1026