I'm running Arch linux on my laptop, which is kernel 3.12.9 right now. Something has changed about the way the kernel maps in a dynamically-linked executable and I can't figure it out.  Here's the example:% /usr/bin/cat /proc/self/maps...00400000-0040b000 r-xp 00000000 08:02 1186756             /usr/bin/cat0060a000-0060b000 r--p 0000a000 08:02 1186756             /usr/bin/cat0060b000-0060c000 rw-p 0000b000 08:02 1186756             /usr/bin/cat00d6c000-00d8d000 rw-p 00000000 00:00 0                   [heap]7f29b3485000-7f29b3623000 r-xp 00000000 08:02 1182988     /usr/lib/libc-2.19.so...My question is: what is the third mapping from /usr/bin/cat?Based on readelf -l /usr/bin/cat, there's a loadable segment of 0x1f8 bytes that should map at 0x400000.  There's a loadable segment of 0xae10 bytes at 0x60ae10. Those two pieces of file correspond to the 00400000-0040b000 mapping, and the 0060a000-0060b000 mapping. But the third mapping, which claims to be at a file offset of 0xb000 bytes, doesn't seem to correspond to any Elf64_Phdr. In fact, the elf header only has 2 PT_LOAD segments.I read through fs/binfm_elf.c in the kernel 3.13.2 source code, and I don't see that the kernel maps in anything other than PT_LOAD segments. If I run strace -o trace.out /usr/bin/cat /proc/self/maps, I don't see any mmap() calls that would map in a piece of /usr/bin/cat, so that 3rd piece is mapped in by the kernel.I ran the same command (cat /proc/self/maps) on a RHEL server that was running kernel 2.6.18 + RH patches. That only shows 2 pieces of /usr/bin/cat mapped into memory, so this might be new with kernel 3.x.
/proc/self/maps - 3rd mapped piece of file?
linux;executable;proc
I finally figured this out. The kernel does map only 2 segments. The third piece is a portion of one of the two loaded by the kernel. The run time linker, the program named in the INTERP pheader, which is /usr/lib/ld-2.24.so for me right now, changes the permissions on the mappings using mprotect() so that there are read/write global variables, read-only global variables, and a read/execute text segment. You can see this happen using strace, but it's easy to miss, as it's only a single mprotect() call.It wasn't a kernel change that caused this, it was a GNU lib C change.