Re: /proc/pid/maps containg anonymous maps that have PROT_NONE

[TÃrÃk Edwin]

On 2008-11-05 18:12, Hugh Dickins wrote:
> On Wed, 5 Nov 2008, TÃrÃk Edwin wrote:
>   
>> I noticed that there are (quite large) entries in /proc/pid/maps that
>> have PROT_NONE, right after an existing mapping:
>> 7fffe4000000-7fffe406a000 rw-p 7fffe4000000 00:00 0
>> 7fffe406a000-7fffe8000000 ---p 7fffe406a000 00:00 0
>> 7ffff76d1000-7ffff76e0000 r-xp 00000000 09:03 260750                    
>> /lib/libbz2.so.1.0.4
>> 7ffff76e0000-7ffff78df000 ---p 0000f000 09:03 260750                    
>> /lib/libbz2.so.1.0.4
>>
>> I don't mind that 2Mb map, but what is 7fffe406a000-7fffe8000000 ---p ?
>> (63M)
>>
>> Is it coming from glibc mapping memory as PROT_NONE, and using
>> mprotect/madvise to make it writable, and then
>> caching the mappings for future use, rather than freeing them?
>>     
>
> mmap PROT_NONE to reserve an arena, munmap to trim off top and bottom,
> mprotect to make areas read+writable, madvise 0x4 to say MADV_DONTNEED
> on some parts.  gcc?  Or the application itself (clamd) and its libs?
>
>   
>> I straced the program creating these, and I couldn't find anything with
>> 7fffe406a000, but only before that address:
>>
>> [pid 31928] mprotect(0x7fffe4000000, 135168, PROT_READ|PROT_WRITE) = 0
>>     
> [snipped]
>   
>> [pid 31928] madvise(0x7fffe4021000, 4096, 0x4 /* MADV_??? */) = 0
>>
>> There is an mprotect and madvise that end at 0x7fffe406a000.
>> Those mprotects and madvise are coming from glibc. Its strange that I
>> don't see the mmap only the mprotect, but I used strace -f.
>>
>> This happens on:
>> Linux debian 2.6.26-1-amd64 #1 SMP Thu Oct 9 14:16:53 UTC 2008 x86_64
>> GNU/Linux
>>
>> strace is here:
>> http://edwintorok.googlepages.com/log2.bz2
>>     
>
> Just before your first mprotect above there's:
>
> [pid 31928] mmap(NULL, 134217728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0 <unfinished ...>
> [pid 31938] futex(0x7ffff6e489e0, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
> [pid 31928] <... mmap resumed> )        = 0x7fffe2bd3000
>
>   which maps 7fffe2bd3000-7fffeabd3000; then
>
> [pid 31928] munmap(0x7fffe2bd3000, 21155840 <unfinished ...>
> [pid 31938] <... futex resumed> )       = 0
> [pid 31928] <... munmap resumed> )      = 0
>
>   which unmaps 7fffe2bd3000-7fffe4000000; and then
>
> [pid 31928] munmap(0x7fffe8000000, 45953024) = 0
>
>   which unmaps 7fffe8000000-7fffeabd3000.
>
> So it's trimming off the rough edges to leave 7fffe4000000-7fffe8000000
> mapped PROT_NONE, then mprotecting what it needs of that.
>
>   

Thanks I completely missed the mmap, because I grepped for 7fffe4000000.

> Why does it mmap too much then trim it down?  Perhaps it's trying to
> minimize pagetable usage, perhaps it's internally convenient to base
> on rounded addresses, I don't know.
>
> But the mmap is there: just easily overlooked because of the way it
> munmaps too (with strace showing hex addresses but decimal sizes).

I will get some stacktraces and figure out, know that I know which mmap
to look for (the one with MAP_NORESERVE).

Best regards,
--Edwin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/