On Apr 25 2007 11:30, Eric Dumazet wrote:
>Jakub Jelinek <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
