Re: Big reserved mappings on x86_64

[Jan Engelhardt <jengelh@linux01.gwdg.de>]

On Apr 25 2007 11:30, Eric Dumazet wrote:
>Jakub Jelinek <jakub@redhat.com> 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
>> > START       SIZE     RSS   DIRTY PERM MAPPING
>> > 2ae6cca70000    212K    172K      0K r-xp /lib64/libreadline.so.5.2
>> > 2ae6ccaa5000   2044K      0K      0K ---p /lib64/libreadline.so.5.2 <--
>> > 2ae6ccca4000      4K      4K      4K r--p /lib64/libreadline.so.5.2
>> > 2ae6ccca5000     28K     28K     28K rw-p /lib64/libreadline.so.5.2
>> > 2ae6cccac000      8K      8K      8K rw-p [anon]
>> > 2ae6cccae000     28K     16K      0K r-xp /lib64/libhistory.so.5.2
>> > 2ae6cccb5000   2048K      0K      0K ---p /lib64/libhistory.so.5.2 <--
>> > 2ae6cceb5000      8K      8K      8K rw-p /lib64/libhistory.so.5.2
>> > 2ae6cceb7000    320K    208K      0K r-xp /lib64/libncurses.so.5.5
>> > 2ae6ccf07000   2048K      0K      0K ---p /lib64/libncurses.so.5.5 <--
>> > 2ae6cd107000     48K     48K     48K r--p /lib64/libncurses.so.5.5
>> > 2ae6cd113000     28K     28K     28K rw-p /lib64/libncurses.so.5.5
>> > [...]
>> > 
>> > 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 ld.so
>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/libc-2.5.so
f7e8c000     56K -----  /lib/libc-2.5.so <-
f7e9a000      8K r----  /lib/libc-2.5.so
f7e9c000     16K rwx--  /lib/libc-2.5.so
f7ea0000      8K rwx--    [ anon ]
f7ea4000     16K r-x--  /lib/libdl-2.5.so
f7ea8000     56K -----  /lib/libdl-2.5.so <-
f7eb6000      8K r----  /lib/libdl-2.5.so
f7eb8000      8K rwx--  /lib/libdl-2.5.so
f7ebc000     16K r-x--  /lib/libtermcap.so.2.0.8
f7ec0000     56K -----  /lib/libtermcap.so.2.0.8 <-
f7ece000      8K rwx--  /lib/libtermcap.so.2.0.8


Jan
-- 
-
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/