Messages in this thread | | | Date | Wed, 05 Nov 2008 19:56:06 +0200 | From | Török Edwin <> | Subject | Re: /proc/pid/maps containg anonymous maps that have PROT_NONE |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |