Re: Big reserved mappings on x86_64

From: Jan Engelhardt
Date: Wed Apr 25 2007 - 06:01:41 EST

On Apr 25 2007 11:30, Eric Dumazet wrote:
>Jakub Jelinek <jakub@xxxxxxxxxx> wrote:
>> On Wed, Apr 25, 2007 at 10:42:20AM +0200, Jan Engelhardt wrote:
>> > I actually took a look at `pmap $$`, which reveals that a lot of shared
>> > libraries map 2044K or 2048K unreadable-unwritable-private
>> > mappings...for _what_ purpose?
>> >
>> > 10:37 opteron:~ > pmap $$
>> > 4403: bash
>> > 2ae6cca70000 212K 172K 0K r-xp /lib64/
>> > 2ae6ccaa5000 2044K 0K 0K ---p /lib64/ <--
>> > 2ae6ccca4000 4K 4K 4K r--p /lib64/
>> > 2ae6ccca5000 28K 28K 28K rw-p /lib64/
>> > 2ae6cccac000 8K 8K 8K rw-p [anon]
>> > 2ae6cccae000 28K 16K 0K r-xp /lib64/
>> > 2ae6cccb5000 2048K 0K 0K ---p /lib64/ <--
>> > 2ae6cceb5000 8K 8K 8K rw-p /lib64/
>> > 2ae6cceb7000 320K 208K 0K r-xp /lib64/
>> > 2ae6ccf07000 2048K 0K 0K ---p /lib64/ <--
>> > 2ae6cd107000 48K 48K 48K r--p /lib64/
>> > 2ae6cd113000 28K 28K 28K rw-p /lib64/
>> > [...]
>> >
>> > What could these ominous mappings be? Does anyone else see that -
>> > perhaps someone with x86_64 && !(opensuse 10.2)?
>> While i386 only supports 4KB pages, x86_64 ELF objects ought to support
>> up to 2MB pages. The gap between read-only/executable and writable segments
>> is intentionally mapped PROT_NONE, so that other things aren't mapped in
>> between the segments.
>This makes sense for catching some programming errors, but it also
>has a cost for innocent users, since it adds one vm_area_struct per
>dll. It slows down all find_vma() operations that tend to be done
>quite frequently these days :( Even with a rbtree, adding 150
>vm_area_struct increase memory needs and cache misses. Maybe these
>PROT_NONE mappings could be done iff some LD_DEBUG or other
>variable says so ?

And even then, there should probably be one or two variables inside
the vma struct that defines a "padding" the must come before/after a
specific vma. I think that would get rid of these PROT_NONE vmas
while catching errors. Hey btw, are there any architectures that do
_not_ actually implement a read/write check? Having no vma mapped at
all might catch a bogus read/write attempt earlier than a prot_none
vma, does not it?

>BTW I dont see such mappings on my 32bit distro (Ubuntu 7.04, glibc-2.5)

It seems specific to x86_64. sparc64 looks like this:

f7d34000 1376K r-x-- /lib/
f7e8c000 56K ----- /lib/ <-
f7e9a000 8K r---- /lib/
f7e9c000 16K rwx-- /lib/
f7ea0000 8K rwx-- [ anon ]
f7ea4000 16K r-x-- /lib/
f7ea8000 56K ----- /lib/ <-
f7eb6000 8K r---- /lib/
f7eb8000 8K rwx-- /lib/
f7ebc000 16K r-x-- /lib/
f7ec0000 56K ----- /lib/ <-
f7ece000 8K rwx-- /lib/

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at