Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Mike Kravetz]

On 05/31/2018 02:24 AM, Michal Hocko wrote:
> I am not an expert on the load linkers myself so I cannot really answer
> this question. Please note that ppc had something similar. See
> ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments").
> Maybe we need to sprinkle more of those at other places?

I finally understand the issue, and it is NOT a problem with the kernel.
The issue is with old libhugetlbfs provided linker scripts, and yes,
starting with v4.17 people who run libhugetlbfs tests on x86 (at least)
will see additional failures.

I'll try to work this from the libhugetlbfs side.  In the unlikely event
that anyone knows about those linker scripts, assistance and/or feedback
would be appreciated.

Read on only if you want additional details about this failure.

The executable files which are now failing are created with the elf_i386.xB
linker script.  This script is provided for pre-2.17 versions of binutils.
binutils-2.17 came out aprox in 2007, and this script is disabled by default
if binutils-2.17 or later is used.  The only way to create executables with
this script today is by setting the HUGETLB_DEPRECATED_LINK env variable.
This is what libhugetlbfs tests do to simply continue testing the old scripts.

I previously was mistaken about which tests were causing the additional
failures.  The example I previously provided failed on v4.16 as well as
v4.17-rc kernels.  So, please ignore that information.

For an executable that runs on v4.16 and fails on v4.17-rc, here is a listing
of elf sections that the kernel will attempt to load.

Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
LOAD   0x00 0x08048000 0x08048000 0x11c24 0x11c24 R E 0x1000
LOAD   0x011c24 0x08059c24 0x08059c24 0x10d04 0x10d04 RW  0x1000
LOAD   0x023000 0x0900 0x0900 0x0 0x10048 RWE 0x1000

The first section is loaded without issue.  elf_map() will create a vma
based on the following:
map_addr ELF_PAGESTART(addr) 8048000 ELF_PAGEALIGN(size) 12000 
File_offset 0

We then attempt to load the following section with:
map_addr ELF_PAGESTART(addr) 8059000 ELF_PAGEALIGN(size) 12000
File_offset 11000

This results in,
Uhuuh, elf segment at 8059000 requested but the memory is mapped already

Note that the last page of the first section overlaps with the first page
of the second section.  Unlike the case in ad55eac74f20, the access
permissions on section 1 (RE) are different than section 2 (RW).  If we
allowed the previous MAP_FIXED behavior, we would be changing part of a
read only section to read write.  This is exactly what MAP_FIXED_NOREPLACE
was designed to prevent.
-- 
Mike Kravetz

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Mike Kravetz]

On 05/31/2018 02:24 AM, Michal Hocko wrote:
> I am not an expert on the load linkers myself so I cannot really answer
> this question. Please note that ppc had something similar. See
> ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments").
> Maybe we need to sprinkle more of those at other places?

I finally understand the issue, and it is NOT a problem with the kernel.
The issue is with old libhugetlbfs provided linker scripts, and yes,
starting with v4.17 people who run libhugetlbfs tests on x86 (at least)
will see additional failures.

I'll try to work this from the libhugetlbfs side.  In the unlikely event
that anyone knows about those linker scripts, assistance and/or feedback
would be appreciated.

Read on only if you want additional details about this failure.

The executable files which are now failing are created with the elf_i386.xB
linker script.  This script is provided for pre-2.17 versions of binutils.
binutils-2.17 came out aprox in 2007, and this script is disabled by default
if binutils-2.17 or later is used.  The only way to create executables with
this script today is by setting the HUGETLB_DEPRECATED_LINK env variable.
This is what libhugetlbfs tests do to simply continue testing the old scripts.

I previously was mistaken about which tests were causing the additional
failures.  The example I previously provided failed on v4.16 as well as
v4.17-rc kernels.  So, please ignore that information.

For an executable that runs on v4.16 and fails on v4.17-rc, here is a listing
of elf sections that the kernel will attempt to load.

Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
LOAD   0x00 0x08048000 0x08048000 0x11c24 0x11c24 R E 0x1000
LOAD   0x011c24 0x08059c24 0x08059c24 0x10d04 0x10d04 RW  0x1000
LOAD   0x023000 0x0900 0x0900 0x0 0x10048 RWE 0x1000

The first section is loaded without issue.  elf_map() will create a vma
based on the following:
map_addr ELF_PAGESTART(addr) 8048000 ELF_PAGEALIGN(size) 12000 
File_offset 0

We then attempt to load the following section with:
map_addr ELF_PAGESTART(addr) 8059000 ELF_PAGEALIGN(size) 12000
File_offset 11000

This results in,
Uhuuh, elf segment at 8059000 requested but the memory is mapped already

Note that the last page of the first section overlaps with the first page
of the second section.  Unlike the case in ad55eac74f20, the access
permissions on section 1 (RE) are different than section 2 (RW).  If we
allowed the previous MAP_FIXED behavior, we would be changing part of a
read only section to read write.  This is exactly what MAP_FIXED_NOREPLACE
was designed to prevent.
-- 
Mike Kravetz

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Michal Hocko]

On Wed 30-05-18 17:51:15, Mike Kravetz wrote:
[...]
> [   38.931497] load_elf_binary: skipping index 0 p_vaddr = 8048034
> [   38.932321] load_elf_binary: skipping index 1 p_vaddr = 8048154
> [   38.933165] load_elf_binary: calling elf_map() index 2 bias 0 vaddr 8048000
> [   38.934087] map_addr ELF_PAGESTART(addr) 8048000 total_size 0 
> ELF_PAGEALIGN(size) 2000
> [   38.935101] eppnt->p_offset = 0
> [   38.935561] eppnt->p_vaddr  = 8048000
> [   38.936073] eppnt->p_paddr  = 8048000
> [   38.936897] eppnt->p_filesz = 169c
> [   38.937493] eppnt->p_memsz  = 169c
> [   38.938042] load_elf_binary: calling elf_map() index 3 bias 0 vaddr 804969c
> [   38.939002] map_addr ELF_PAGESTART(addr) 8049000 total_size 0 
> ELF_PAGEALIGN(size) 2000
> [   38.939959] eppnt->p_offset = 169c
> [   38.940410] eppnt->p_vaddr  = 804969c
> [   38.940897] eppnt->p_paddr  = 804969c
> [   38.941507] eppnt->p_filesz = 1878
> [   38.942019] eppnt->p_memsz  = 1878
> [   38.942516] 1123 (xB.linkhuge_nof): Uhuuh, elf segment at 8049000 
> requested but the memory is mapped already
> 
> It is pretty easy to see the mmap conflict.  I'm still trying to determine if
> the executable file is 'valid'.  It did not throw an error previously as
> MAP_FIXED unmapped the overlapping page.  However, this does not seem right.

Yes, it looks suspicious to say the least. How come the original content
is not needed anymore? Maybe the first section should be 0x1000 rather
than 0x169c?

I am not an expert on the load linkers myself so I cannot really answer
this question. Please note that ppc had something similar. See
ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments").
Maybe we need to sprinkle more of those at other places?
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Michal Hocko]

On Wed 30-05-18 17:51:15, Mike Kravetz wrote:
[...]
> [   38.931497] load_elf_binary: skipping index 0 p_vaddr = 8048034
> [   38.932321] load_elf_binary: skipping index 1 p_vaddr = 8048154
> [   38.933165] load_elf_binary: calling elf_map() index 2 bias 0 vaddr 8048000
> [   38.934087] map_addr ELF_PAGESTART(addr) 8048000 total_size 0 
> ELF_PAGEALIGN(size) 2000
> [   38.935101] eppnt->p_offset = 0
> [   38.935561] eppnt->p_vaddr  = 8048000
> [   38.936073] eppnt->p_paddr  = 8048000
> [   38.936897] eppnt->p_filesz = 169c
> [   38.937493] eppnt->p_memsz  = 169c
> [   38.938042] load_elf_binary: calling elf_map() index 3 bias 0 vaddr 804969c
> [   38.939002] map_addr ELF_PAGESTART(addr) 8049000 total_size 0 
> ELF_PAGEALIGN(size) 2000
> [   38.939959] eppnt->p_offset = 169c
> [   38.940410] eppnt->p_vaddr  = 804969c
> [   38.940897] eppnt->p_paddr  = 804969c
> [   38.941507] eppnt->p_filesz = 1878
> [   38.942019] eppnt->p_memsz  = 1878
> [   38.942516] 1123 (xB.linkhuge_nof): Uhuuh, elf segment at 8049000 
> requested but the memory is mapped already
> 
> It is pretty easy to see the mmap conflict.  I'm still trying to determine if
> the executable file is 'valid'.  It did not throw an error previously as
> MAP_FIXED unmapped the overlapping page.  However, this does not seem right.

Yes, it looks suspicious to say the least. How come the original content
is not needed anymore? Maybe the first section should be 0x1000 rather
than 0x169c?

I am not an expert on the load linkers myself so I cannot really answer
this question. Please note that ppc had something similar. See
ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments").
Maybe we need to sprinkle more of those at other places?
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Mike Kravetz]

On 05/30/2018 09:25 AM, Michal Hocko wrote:
> Could you add a debugging data to dump the VMA which overlaps the
> requested adress and who requested that? E.g. hook into do_mmap and dump
> all requests from the linker.

Here you go.  I added a bunch of stuff as I clearly do not understand
how elf loading works.  To me, the 'sections' parsed by the kernel code
do not seem to directly align with those produced by objdump.

[   38.899260] load_elf_binary: attempting to load file 
./tests/obj32/xB.linkhuge_nofd
[   38.902340] dumping section headers
[   38.903534] index 0 p_offset = 34
[   38.904683] index 0 p_vaddr  = 8048034
[   38.905680] index 0 p_paddr  = 8048034
[   38.906442] index 0 p_filesz = 120
[   38.907110] index 0 p_memsz  = 120
[   38.907764] 
[   38.908019] index 1 p_offset = 154
[   38.908521] index 1 p_vaddr  = 8048154
[   38.909081] index 1 p_paddr  = 8048154
[   38.909496] index 1 p_filesz = 13
[   38.909855] index 1 p_memsz  = 13
[   38.910453] 
[   38.910731] index 2 p_offset = 0
[   38.911317] index 2 p_vaddr  = 8048000
[   38.911997] index 2 p_paddr  = 8048000
[   38.912590] index 2 p_filesz = 169c
[   38.913141] index 2 p_memsz  = 169c
[   38.913713] 
[   38.913987] index 3 p_offset = 169c
[   38.914518] index 3 p_vaddr  = 804969c
[   38.915101] index 3 p_paddr  = 804969c
[   38.915718] index 3 p_filesz = 1878
[   38.916266] index 3 p_memsz  = 1878
[   38.916799] 
[   38.917032] index 4 p_offset = 3000
[   38.917537] index 4 p_vaddr  = 900
[   38.918119] index 4 p_paddr  = 900
[   38.918709] index 4 p_filesz = 0
[   38.919525] index 4 p_memsz  = 10
[   38.919993] 
[   38.920275] index 5 p_offset = 2d88
[   38.920791] index 5 p_vaddr  = 804ad88
[   38.921307] index 5 p_paddr  = 804ad88
[   38.921800] index 5 p_filesz = 18c
[   38.922288] index 5 p_memsz  = 18c
[   38.922739] 
[   38.922973] index 6 p_offset = 168
[   38.923431] index 6 p_vaddr  = 8048168
[   38.923946] index 6 p_paddr  = 8048168
[   38.924457] index 6 p_filesz = 44
[   38.924931] index 6 p_memsz  = 44
[   38.925414] 
[   38.925593] index 7 p_offset = 0
[   38.926031] index 7 p_vaddr  = 0
[   38.926510] index 7 p_paddr  = 0
[   38.926957] index 7 p_filesz = 0
[   38.927443] index 7 p_memsz  = 0
[   38.927879] 
[   38.928115] index 8 p_offset = 169c
[   38.928594] index 8 p_vaddr  = 804969c
[   38.929091] index 8 p_paddr  = 804969c
[   38.929646] index 8 p_filesz = 8c
[   38.930177] index 8 p_memsz  = 8c
[   38.930710] 
[   38.931497] load_elf_binary: skipping index 0 p_vaddr = 8048034
[   38.932321] load_elf_binary: skipping index 1 p_vaddr = 8048154
[   38.933165] load_elf_binary: calling elf_map() index 2 bias 0 vaddr 8048000
[   38.934087] map_addr ELF_PAGESTART(addr) 8048000 total_size 0 
ELF_PAGEALIGN(size) 2000
[   38.935101] eppnt->p_offset = 0
[   38.935561] eppnt->p_vaddr  = 8048000
[   38.936073] eppnt->p_paddr  = 8048000
[   38.936897] eppnt->p_filesz = 169c
[   38.937493] eppnt->p_memsz  = 169c
[   38.938042] load_elf_binary: calling elf_map() index 3 bias 0 vaddr 804969c
[   38.939002] map_addr ELF_PAGESTART(addr) 8049000 total_size 0 
ELF_PAGEALIGN(size) 2000
[   38.939959] eppnt->p_offset = 169c
[   38.940410] eppnt->p_vaddr  = 804969c
[   38.940897] eppnt->p_paddr  = 804969c
[   38.941507] eppnt->p_filesz = 1878
[   38.942019] eppnt->p_memsz  = 1878
[   38.942516] 1123 (xB.linkhuge_nof): Uhuuh, elf segment at 8049000 requested 
but the memory is mapped already

It is pretty easy to see the mmap conflict.  I'm still trying to determine if
the executable file is 'valid'.  It did not throw an error previously as
MAP_FIXED unmapped the overlapping page.  However, this does not seem right.
-- 
Mike Kravetz

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Mike Kravetz]

On 05/30/2018 09:25 AM, Michal Hocko wrote:
> Could you add a debugging data to dump the VMA which overlaps the
> requested adress and who requested that? E.g. hook into do_mmap and dump
> all requests from the linker.

Here you go.  I added a bunch of stuff as I clearly do not understand
how elf loading works.  To me, the 'sections' parsed by the kernel code
do not seem to directly align with those produced by objdump.

[   38.899260] load_elf_binary: attempting to load file 
./tests/obj32/xB.linkhuge_nofd
[   38.902340] dumping section headers
[   38.903534] index 0 p_offset = 34
[   38.904683] index 0 p_vaddr  = 8048034
[   38.905680] index 0 p_paddr  = 8048034
[   38.906442] index 0 p_filesz = 120
[   38.907110] index 0 p_memsz  = 120
[   38.907764] 
[   38.908019] index 1 p_offset = 154
[   38.908521] index 1 p_vaddr  = 8048154
[   38.909081] index 1 p_paddr  = 8048154
[   38.909496] index 1 p_filesz = 13
[   38.909855] index 1 p_memsz  = 13
[   38.910453] 
[   38.910731] index 2 p_offset = 0
[   38.911317] index 2 p_vaddr  = 8048000
[   38.911997] index 2 p_paddr  = 8048000
[   38.912590] index 2 p_filesz = 169c
[   38.913141] index 2 p_memsz  = 169c
[   38.913713] 
[   38.913987] index 3 p_offset = 169c
[   38.914518] index 3 p_vaddr  = 804969c
[   38.915101] index 3 p_paddr  = 804969c
[   38.915718] index 3 p_filesz = 1878
[   38.916266] index 3 p_memsz  = 1878
[   38.916799] 
[   38.917032] index 4 p_offset = 3000
[   38.917537] index 4 p_vaddr  = 900
[   38.918119] index 4 p_paddr  = 900
[   38.918709] index 4 p_filesz = 0
[   38.919525] index 4 p_memsz  = 10
[   38.919993] 
[   38.920275] index 5 p_offset = 2d88
[   38.920791] index 5 p_vaddr  = 804ad88
[   38.921307] index 5 p_paddr  = 804ad88
[   38.921800] index 5 p_filesz = 18c
[   38.922288] index 5 p_memsz  = 18c
[   38.922739] 
[   38.922973] index 6 p_offset = 168
[   38.923431] index 6 p_vaddr  = 8048168
[   38.923946] index 6 p_paddr  = 8048168
[   38.924457] index 6 p_filesz = 44
[   38.924931] index 6 p_memsz  = 44
[   38.925414] 
[   38.925593] index 7 p_offset = 0
[   38.926031] index 7 p_vaddr  = 0
[   38.926510] index 7 p_paddr  = 0
[   38.926957] index 7 p_filesz = 0
[   38.927443] index 7 p_memsz  = 0
[   38.927879] 
[   38.928115] index 8 p_offset = 169c
[   38.928594] index 8 p_vaddr  = 804969c
[   38.929091] index 8 p_paddr  = 804969c
[   38.929646] index 8 p_filesz = 8c
[   38.930177] index 8 p_memsz  = 8c
[   38.930710] 
[   38.931497] load_elf_binary: skipping index 0 p_vaddr = 8048034
[   38.932321] load_elf_binary: skipping index 1 p_vaddr = 8048154
[   38.933165] load_elf_binary: calling elf_map() index 2 bias 0 vaddr 8048000
[   38.934087] map_addr ELF_PAGESTART(addr) 8048000 total_size 0 
ELF_PAGEALIGN(size) 2000
[   38.935101] eppnt->p_offset = 0
[   38.935561] eppnt->p_vaddr  = 8048000
[   38.936073] eppnt->p_paddr  = 8048000
[   38.936897] eppnt->p_filesz = 169c
[   38.937493] eppnt->p_memsz  = 169c
[   38.938042] load_elf_binary: calling elf_map() index 3 bias 0 vaddr 804969c
[   38.939002] map_addr ELF_PAGESTART(addr) 8049000 total_size 0 
ELF_PAGEALIGN(size) 2000
[   38.939959] eppnt->p_offset = 169c
[   38.940410] eppnt->p_vaddr  = 804969c
[   38.940897] eppnt->p_paddr  = 804969c
[   38.941507] eppnt->p_filesz = 1878
[   38.942019] eppnt->p_memsz  = 1878
[   38.942516] 1123 (xB.linkhuge_nof): Uhuuh, elf segment at 8049000 requested 
but the memory is mapped already

It is pretty easy to see the mmap conflict.  I'm still trying to determine if
the executable file is 'valid'.  It did not throw an error previously as
MAP_FIXED unmapped the overlapping page.  However, this does not seem right.
-- 
Mike Kravetz

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Michal Hocko]

On Wed 30-05-18 08:00:29, Mike Kravetz wrote:
> On 05/30/2018 01:02 AM, Michal Hocko wrote:
> > On Tue 29-05-18 15:21:14, Mike Kravetz wrote:
> >> Just a quick heads up.  I noticed a change in libhugetlbfs testing starting
> >> with v4.17-rc1.
> >>
> >> V4.16 libhugetlbfs test results
> >> ** TEST SUMMARY
> >> *  2M
> >> *  32-bit 64-bit 
> >> * Total testcases:   110113   
> >> * Skipped: 0  0   
> >> *PASS:   105111   
> >> *FAIL: 0  0   
> >> *Killed by signal: 4  1   
> >> *   Bad configuration: 1  1   
> >> *   Expected FAIL: 0  0   
> >> * Unexpected PASS: 0  0   
> >> *Test not present: 0  0   
> >> * Strange test result: 0  0   
> >> **
> >>
> >> v4.17-rc1 (and later) libhugetlbfs test results
> >> ** TEST SUMMARY
> >> *  2M
> >> *  32-bit 64-bit 
> >> * Total testcases:   110113   
> >> * Skipped: 0  0   
> >> *PASS:98111   
> >> *FAIL: 0  0   
> >> *Killed by signal:11  1   
> >> *   Bad configuration: 1  1   
> >> *   Expected FAIL: 0  0   
> >> * Unexpected PASS: 0  0   
> >> *Test not present: 0  0   
> >> * Strange test result: 0  0   
> >> **
> >>
> >> I traced the 7 additional (32-bit) killed by signal results to this
> >> commit 4ed28639519c fs, elf: drop MAP_FIXED usage from elf_map.
> >>
> >> libhugetlbfs does unusual things and even provides custom linker scripts.
> >> So, in hindsight this change in behavior does not seem too unexpected.  I
> >> JUST discovered this while running libhugetlbfs tests for an unrelated
> >> issue/change and, will do some analysis to see exactly what is happening.
> > 
> > I am definitely interested about further details. Are there any messages
> > in the kernel log?
> >
> 
> Yes, new messages associated with the failures.
> 
> [   47.570451] 1368 (xB.linkhuge_nof): Uhuuh, elf segment at a731413b 
> requested but the memory is mapped already
> [   47.606991] 1372 (xB.linkhuge_nof): Uhuuh, elf segment at a731413b 
> requested but the memory is mapped already
> [   47.641351] 1376 (xB.linkhuge_nof): Uhuuh, elf segment at a731413b 
> requested but the memory is mapped already
> [   47.726138] 1384 (xB.linkhuge): Uhuuh, elf segment at 90b9eaf6 
> requested but the memory is mapped already
> [   47.773169] 1393 (xB.linkhuge): Uhuuh, elf segment at 90b9eaf6 
> requested but the memory is mapped already
> [   47.817788] 1402 (xB.linkhuge): Uhuuh, elf segment at 90b9eaf6 
> requested but the memory is mapped already
> [   47.857338] 1406 (xB.linkshare): Uhuuh, elf segment at 18430471 
> requested but the memory is mapped already
> [   47.956355] 1427 (xB.linkshare): Uhuuh, elf segment at 18430471 
> requested but the memory is mapped already
> [   48.054894] 1448 (xB.linkhuge): Uhuuh, elf segment at 90b9eaf6 
> requested but the memory is mapped already
> [   48.071221] 1451 (xB.linkhuge): Uhuuh, elf segment at 90b9eaf6 
> requested but the memory is mapped already
> 
> Just curious, the addresses printed in those messages does not seem correct.
> They should be page aligned.  Correct?

I have no idea what the loader actually does here.

> I think that %p conversion in the pr_info() may doing something wrong.

Well, we are using %px and that shouldn't do any tricks to the given
address.

> Also, the new failures in question are indeed being built with custom linker
> scripts designed for use with binutils older than 2.16 (really old).  So, no
> new users should encounter this issue (I think).  It appears that this may
> only impact old applications built long ago with pre-2.16 binutils.

Could you add a debugging data to dump the VMA which overlaps the
requested adress and who requested that? E.g. hook into do_mmap and dump
all requests from the linker.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Michal Hocko]

On Wed 30-05-18 08:00:29, Mike Kravetz wrote:
> On 05/30/2018 01:02 AM, Michal Hocko wrote:
> > On Tue 29-05-18 15:21:14, Mike Kravetz wrote:
> >> Just a quick heads up.  I noticed a change in libhugetlbfs testing starting
> >> with v4.17-rc1.
> >>
> >> V4.16 libhugetlbfs test results
> >> ** TEST SUMMARY
> >> *  2M
> >> *  32-bit 64-bit 
> >> * Total testcases:   110113   
> >> * Skipped: 0  0   
> >> *PASS:   105111   
> >> *FAIL: 0  0   
> >> *Killed by signal: 4  1   
> >> *   Bad configuration: 1  1   
> >> *   Expected FAIL: 0  0   
> >> * Unexpected PASS: 0  0   
> >> *Test not present: 0  0   
> >> * Strange test result: 0  0   
> >> **
> >>
> >> v4.17-rc1 (and later) libhugetlbfs test results
> >> ** TEST SUMMARY
> >> *  2M
> >> *  32-bit 64-bit 
> >> * Total testcases:   110113   
> >> * Skipped: 0  0   
> >> *PASS:98111   
> >> *FAIL: 0  0   
> >> *Killed by signal:11  1   
> >> *   Bad configuration: 1  1   
> >> *   Expected FAIL: 0  0   
> >> * Unexpected PASS: 0  0   
> >> *Test not present: 0  0   
> >> * Strange test result: 0  0   
> >> **
> >>
> >> I traced the 7 additional (32-bit) killed by signal results to this
> >> commit 4ed28639519c fs, elf: drop MAP_FIXED usage from elf_map.
> >>
> >> libhugetlbfs does unusual things and even provides custom linker scripts.
> >> So, in hindsight this change in behavior does not seem too unexpected.  I
> >> JUST discovered this while running libhugetlbfs tests for an unrelated
> >> issue/change and, will do some analysis to see exactly what is happening.
> > 
> > I am definitely interested about further details. Are there any messages
> > in the kernel log?
> >
> 
> Yes, new messages associated with the failures.
> 
> [   47.570451] 1368 (xB.linkhuge_nof): Uhuuh, elf segment at a731413b 
> requested but the memory is mapped already
> [   47.606991] 1372 (xB.linkhuge_nof): Uhuuh, elf segment at a731413b 
> requested but the memory is mapped already
> [   47.641351] 1376 (xB.linkhuge_nof): Uhuuh, elf segment at a731413b 
> requested but the memory is mapped already
> [   47.726138] 1384 (xB.linkhuge): Uhuuh, elf segment at 90b9eaf6 
> requested but the memory is mapped already
> [   47.773169] 1393 (xB.linkhuge): Uhuuh, elf segment at 90b9eaf6 
> requested but the memory is mapped already
> [   47.817788] 1402 (xB.linkhuge): Uhuuh, elf segment at 90b9eaf6 
> requested but the memory is mapped already
> [   47.857338] 1406 (xB.linkshare): Uhuuh, elf segment at 18430471 
> requested but the memory is mapped already
> [   47.956355] 1427 (xB.linkshare): Uhuuh, elf segment at 18430471 
> requested but the memory is mapped already
> [   48.054894] 1448 (xB.linkhuge): Uhuuh, elf segment at 90b9eaf6 
> requested but the memory is mapped already
> [   48.071221] 1451 (xB.linkhuge): Uhuuh, elf segment at 90b9eaf6 
> requested but the memory is mapped already
> 
> Just curious, the addresses printed in those messages does not seem correct.
> They should be page aligned.  Correct?

I have no idea what the loader actually does here.

> I think that %p conversion in the pr_info() may doing something wrong.

Well, we are using %px and that shouldn't do any tricks to the given
address.

> Also, the new failures in question are indeed being built with custom linker
> scripts designed for use with binutils older than 2.16 (really old).  So, no
> new users should encounter this issue (I think).  It appears that this may
> only impact old applications built long ago with pre-2.16 binutils.

Could you add a debugging data to dump the VMA which overlaps the
requested adress and who requested that? E.g. hook into do_mmap and dump
all requests from the linker.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Mike Kravetz]

On 05/30/2018 01:02 AM, Michal Hocko wrote:
> On Tue 29-05-18 15:21:14, Mike Kravetz wrote:
>> Just a quick heads up.  I noticed a change in libhugetlbfs testing starting
>> with v4.17-rc1.
>>
>> V4.16 libhugetlbfs test results
>> ** TEST SUMMARY
>> *  2M
>> *  32-bit 64-bit 
>> * Total testcases:   110113   
>> * Skipped: 0  0   
>> *PASS:   105111   
>> *FAIL: 0  0   
>> *Killed by signal: 4  1   
>> *   Bad configuration: 1  1   
>> *   Expected FAIL: 0  0   
>> * Unexpected PASS: 0  0   
>> *Test not present: 0  0   
>> * Strange test result: 0  0   
>> **
>>
>> v4.17-rc1 (and later) libhugetlbfs test results
>> ** TEST SUMMARY
>> *  2M
>> *  32-bit 64-bit 
>> * Total testcases:   110113   
>> * Skipped: 0  0   
>> *PASS:98111   
>> *FAIL: 0  0   
>> *Killed by signal:11  1   
>> *   Bad configuration: 1  1   
>> *   Expected FAIL: 0  0   
>> * Unexpected PASS: 0  0   
>> *Test not present: 0  0   
>> * Strange test result: 0  0   
>> **
>>
>> I traced the 7 additional (32-bit) killed by signal results to this
>> commit 4ed28639519c fs, elf: drop MAP_FIXED usage from elf_map.
>>
>> libhugetlbfs does unusual things and even provides custom linker scripts.
>> So, in hindsight this change in behavior does not seem too unexpected.  I
>> JUST discovered this while running libhugetlbfs tests for an unrelated
>> issue/change and, will do some analysis to see exactly what is happening.
> 
> I am definitely interested about further details. Are there any messages
> in the kernel log?
>

Yes, new messages associated with the failures.

[   47.570451] 1368 (xB.linkhuge_nof): Uhuuh, elf segment at a731413b 
requested but the memory is mapped already
[   47.606991] 1372 (xB.linkhuge_nof): Uhuuh, elf segment at a731413b 
requested but the memory is mapped already
[   47.641351] 1376 (xB.linkhuge_nof): Uhuuh, elf segment at a731413b 
requested but the memory is mapped already
[   47.726138] 1384 (xB.linkhuge): Uhuuh, elf segment at 90b9eaf6 
requested but the memory is mapped already
[   47.773169] 1393 (xB.linkhuge): Uhuuh, elf segment at 90b9eaf6 
requested but the memory is mapped already
[   47.817788] 1402 (xB.linkhuge): Uhuuh, elf segment at 90b9eaf6 
requested but the memory is mapped already
[   47.857338] 1406 (xB.linkshare): Uhuuh, elf segment at 18430471 
requested but the memory is mapped already
[   47.956355] 1427 (xB.linkshare): Uhuuh, elf segment at 18430471 
requested but the memory is mapped already
[   48.054894] 1448 (xB.linkhuge): Uhuuh, elf segment at 90b9eaf6 
requested but the memory is mapped already
[   48.071221] 1451 (xB.linkhuge): Uhuuh, elf segment at 90b9eaf6 
requested but the memory is mapped already

Just curious, the addresses printed in those messages does not seem correct.
They should be page aligned.  Correct?  I think that %p conversion in the
pr_info() may doing something wrong.

Also, the new failures in question are indeed being built with custom linker
scripts designed for use with binutils older than 2.16 (really old).  So, no
new users should encounter this issue (I think).  It appears that this may
only impact old applications built long ago with pre-2.16 binutils.
-- 
Mike Kravetz

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Mike Kravetz]

On 05/30/2018 01:02 AM, Michal Hocko wrote:
> On Tue 29-05-18 15:21:14, Mike Kravetz wrote:
>> Just a quick heads up.  I noticed a change in libhugetlbfs testing starting
>> with v4.17-rc1.
>>
>> V4.16 libhugetlbfs test results
>> ** TEST SUMMARY
>> *  2M
>> *  32-bit 64-bit 
>> * Total testcases:   110113   
>> * Skipped: 0  0   
>> *PASS:   105111   
>> *FAIL: 0  0   
>> *Killed by signal: 4  1   
>> *   Bad configuration: 1  1   
>> *   Expected FAIL: 0  0   
>> * Unexpected PASS: 0  0   
>> *Test not present: 0  0   
>> * Strange test result: 0  0   
>> **
>>
>> v4.17-rc1 (and later) libhugetlbfs test results
>> ** TEST SUMMARY
>> *  2M
>> *  32-bit 64-bit 
>> * Total testcases:   110113   
>> * Skipped: 0  0   
>> *PASS:98111   
>> *FAIL: 0  0   
>> *Killed by signal:11  1   
>> *   Bad configuration: 1  1   
>> *   Expected FAIL: 0  0   
>> * Unexpected PASS: 0  0   
>> *Test not present: 0  0   
>> * Strange test result: 0  0   
>> **
>>
>> I traced the 7 additional (32-bit) killed by signal results to this
>> commit 4ed28639519c fs, elf: drop MAP_FIXED usage from elf_map.
>>
>> libhugetlbfs does unusual things and even provides custom linker scripts.
>> So, in hindsight this change in behavior does not seem too unexpected.  I
>> JUST discovered this while running libhugetlbfs tests for an unrelated
>> issue/change and, will do some analysis to see exactly what is happening.
> 
> I am definitely interested about further details. Are there any messages
> in the kernel log?
>

Yes, new messages associated with the failures.

[   47.570451] 1368 (xB.linkhuge_nof): Uhuuh, elf segment at a731413b 
requested but the memory is mapped already
[   47.606991] 1372 (xB.linkhuge_nof): Uhuuh, elf segment at a731413b 
requested but the memory is mapped already
[   47.641351] 1376 (xB.linkhuge_nof): Uhuuh, elf segment at a731413b 
requested but the memory is mapped already
[   47.726138] 1384 (xB.linkhuge): Uhuuh, elf segment at 90b9eaf6 
requested but the memory is mapped already
[   47.773169] 1393 (xB.linkhuge): Uhuuh, elf segment at 90b9eaf6 
requested but the memory is mapped already
[   47.817788] 1402 (xB.linkhuge): Uhuuh, elf segment at 90b9eaf6 
requested but the memory is mapped already
[   47.857338] 1406 (xB.linkshare): Uhuuh, elf segment at 18430471 
requested but the memory is mapped already
[   47.956355] 1427 (xB.linkshare): Uhuuh, elf segment at 18430471 
requested but the memory is mapped already
[   48.054894] 1448 (xB.linkhuge): Uhuuh, elf segment at 90b9eaf6 
requested but the memory is mapped already
[   48.071221] 1451 (xB.linkhuge): Uhuuh, elf segment at 90b9eaf6 
requested but the memory is mapped already

Just curious, the addresses printed in those messages does not seem correct.
They should be page aligned.  Correct?  I think that %p conversion in the
pr_info() may doing something wrong.

Also, the new failures in question are indeed being built with custom linker
scripts designed for use with binutils older than 2.16 (really old).  So, no
new users should encounter this issue (I think).  It appears that this may
only impact old applications built long ago with pre-2.16 binutils.
-- 
Mike Kravetz

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Michal Hocko]

On Tue 29-05-18 15:21:14, Mike Kravetz wrote:
> Just a quick heads up.  I noticed a change in libhugetlbfs testing starting
> with v4.17-rc1.
> 
> V4.16 libhugetlbfs test results
> ** TEST SUMMARY
> *  2M
> *  32-bit 64-bit 
> * Total testcases:   110113   
> * Skipped: 0  0   
> *PASS:   105111   
> *FAIL: 0  0   
> *Killed by signal: 4  1   
> *   Bad configuration: 1  1   
> *   Expected FAIL: 0  0   
> * Unexpected PASS: 0  0   
> *Test not present: 0  0   
> * Strange test result: 0  0   
> **
> 
> v4.17-rc1 (and later) libhugetlbfs test results
> ** TEST SUMMARY
> *  2M
> *  32-bit 64-bit 
> * Total testcases:   110113   
> * Skipped: 0  0   
> *PASS:98111   
> *FAIL: 0  0   
> *Killed by signal:11  1   
> *   Bad configuration: 1  1   
> *   Expected FAIL: 0  0   
> * Unexpected PASS: 0  0   
> *Test not present: 0  0   
> * Strange test result: 0  0   
> **
> 
> I traced the 7 additional (32-bit) killed by signal results to this
> commit 4ed28639519c fs, elf: drop MAP_FIXED usage from elf_map.
> 
> libhugetlbfs does unusual things and even provides custom linker scripts.
> So, in hindsight this change in behavior does not seem too unexpected.  I
> JUST discovered this while running libhugetlbfs tests for an unrelated
> issue/change and, will do some analysis to see exactly what is happening.

I am definitely interested about further details. Are there any messages
in the kernel log?

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Michal Hocko]

On Tue 29-05-18 15:21:14, Mike Kravetz wrote:
> Just a quick heads up.  I noticed a change in libhugetlbfs testing starting
> with v4.17-rc1.
> 
> V4.16 libhugetlbfs test results
> ** TEST SUMMARY
> *  2M
> *  32-bit 64-bit 
> * Total testcases:   110113   
> * Skipped: 0  0   
> *PASS:   105111   
> *FAIL: 0  0   
> *Killed by signal: 4  1   
> *   Bad configuration: 1  1   
> *   Expected FAIL: 0  0   
> * Unexpected PASS: 0  0   
> *Test not present: 0  0   
> * Strange test result: 0  0   
> **
> 
> v4.17-rc1 (and later) libhugetlbfs test results
> ** TEST SUMMARY
> *  2M
> *  32-bit 64-bit 
> * Total testcases:   110113   
> * Skipped: 0  0   
> *PASS:98111   
> *FAIL: 0  0   
> *Killed by signal:11  1   
> *   Bad configuration: 1  1   
> *   Expected FAIL: 0  0   
> * Unexpected PASS: 0  0   
> *Test not present: 0  0   
> * Strange test result: 0  0   
> **
> 
> I traced the 7 additional (32-bit) killed by signal results to this
> commit 4ed28639519c fs, elf: drop MAP_FIXED usage from elf_map.
> 
> libhugetlbfs does unusual things and even provides custom linker scripts.
> So, in hindsight this change in behavior does not seem too unexpected.  I
> JUST discovered this while running libhugetlbfs tests for an unrelated
> issue/change and, will do some analysis to see exactly what is happening.

I am definitely interested about further details. Are there any messages
in the kernel log?

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Mike Kravetz]

Just a quick heads up.  I noticed a change in libhugetlbfs testing starting
with v4.17-rc1.

V4.16 libhugetlbfs test results
** TEST SUMMARY
*  2M
*  32-bit 64-bit 
* Total testcases:   110113   
* Skipped: 0  0   
*PASS:   105111   
*FAIL: 0  0   
*Killed by signal: 4  1   
*   Bad configuration: 1  1   
*   Expected FAIL: 0  0   
* Unexpected PASS: 0  0   
*Test not present: 0  0   
* Strange test result: 0  0   
**

v4.17-rc1 (and later) libhugetlbfs test results
** TEST SUMMARY
*  2M
*  32-bit 64-bit 
* Total testcases:   110113   
* Skipped: 0  0   
*PASS:98111   
*FAIL: 0  0   
*Killed by signal:11  1   
*   Bad configuration: 1  1   
*   Expected FAIL: 0  0   
* Unexpected PASS: 0  0   
*Test not present: 0  0   
* Strange test result: 0  0   
**

I traced the 7 additional (32-bit) killed by signal results to this
commit 4ed28639519c fs, elf: drop MAP_FIXED usage from elf_map.

libhugetlbfs does unusual things and even provides custom linker scripts.
So, in hindsight this change in behavior does not seem too unexpected.  I
JUST discovered this while running libhugetlbfs tests for an unrelated
issue/change and, will do some analysis to see exactly what is happening.

Also, will take it upon myself to run libhugetlbfs test suite on a
regular (at least weekly) basis.
-- 
Mike Kravetz

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Mike Kravetz]

Just a quick heads up.  I noticed a change in libhugetlbfs testing starting
with v4.17-rc1.

V4.16 libhugetlbfs test results
** TEST SUMMARY
*  2M
*  32-bit 64-bit 
* Total testcases:   110113   
* Skipped: 0  0   
*PASS:   105111   
*FAIL: 0  0   
*Killed by signal: 4  1   
*   Bad configuration: 1  1   
*   Expected FAIL: 0  0   
* Unexpected PASS: 0  0   
*Test not present: 0  0   
* Strange test result: 0  0   
**

v4.17-rc1 (and later) libhugetlbfs test results
** TEST SUMMARY
*  2M
*  32-bit 64-bit 
* Total testcases:   110113   
* Skipped: 0  0   
*PASS:98111   
*FAIL: 0  0   
*Killed by signal:11  1   
*   Bad configuration: 1  1   
*   Expected FAIL: 0  0   
* Unexpected PASS: 0  0   
*Test not present: 0  0   
* Strange test result: 0  0   
**

I traced the 7 additional (32-bit) killed by signal results to this
commit 4ed28639519c fs, elf: drop MAP_FIXED usage from elf_map.

libhugetlbfs does unusual things and even provides custom linker scripts.
So, in hindsight this change in behavior does not seem too unexpected.  I
JUST discovered this while running libhugetlbfs tests for an unrelated
issue/change and, will do some analysis to see exactly what is happening.

Also, will take it upon myself to run libhugetlbfs test suite on a
regular (at least weekly) basis.
-- 
Mike Kravetz

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Michal Hocko]

On Wed 18-04-18 20:43:11, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > > Don't complain if IS_ERR_VALUE(),
> > 
> > this is simply wrong. We do want to warn on the failure because this is
> > when the actual clash happens. We should just warn on EEXIST.
> 
> >From 25442cdd31aa5cc8522923a0153a77dfd2ebc832 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa 
> Date: Wed, 18 Apr 2018 20:38:15 +0900
> Subject: [PATCH] fs, elf: don't complain MAP_FIXED_NOREPLACE unless -EEXIST
>  error.
> 
> Commit 4ed28639519c7bad ("fs, elf: drop MAP_FIXED usage from elf_map") is
> printing spurious messages under memory pressure due to map_addr == -ENOMEM.
> 
>  9794 (a.out): Uhuuh, elf segment at 7f2e34738000(fff4) 
> requested but the memory is mapped already
>  14104 (a.out): Uhuuh, elf segment at 7f34fd76c000(fff4) 
> requested but the memory is mapped already
>  16843 (a.out): Uhuuh, elf segment at 7f930ecc7000(fff4) 
> requested but the memory is mapped already
> 
> Complain only if -EEXIST, and use %px for printing the address.

Yes this is better. But...

[...]
> - if ((type & MAP_FIXED_NOREPLACE) && BAD_ADDR(map_addr))
> - pr_info("%d (%s): Uhuuh, elf segment at %p requested but the 
> memory is mapped already\n",
> - task_pid_nr(current), current->comm,
> - (void *)addr);
> + if ((type & MAP_FIXED_NOREPLACE) && map_addr == -EEXIST)

... please use PTR_ERR(map_addr) == -EEXIST

then you can add 
Acked-by: Michal Hocko 

> + pr_info("%d (%s): Uhuuh, elf segment at %px requested but the 
> memory is mapped already\n",
> + task_pid_nr(current), current->comm, (void *)addr);
>  
>   return(map_addr);
>  }
> -- 
> 1.8.3.1

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Michal Hocko]

On Wed 18-04-18 20:43:11, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > > Don't complain if IS_ERR_VALUE(),
> > 
> > this is simply wrong. We do want to warn on the failure because this is
> > when the actual clash happens. We should just warn on EEXIST.
> 
> >From 25442cdd31aa5cc8522923a0153a77dfd2ebc832 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa 
> Date: Wed, 18 Apr 2018 20:38:15 +0900
> Subject: [PATCH] fs, elf: don't complain MAP_FIXED_NOREPLACE unless -EEXIST
>  error.
> 
> Commit 4ed28639519c7bad ("fs, elf: drop MAP_FIXED usage from elf_map") is
> printing spurious messages under memory pressure due to map_addr == -ENOMEM.
> 
>  9794 (a.out): Uhuuh, elf segment at 7f2e34738000(fff4) 
> requested but the memory is mapped already
>  14104 (a.out): Uhuuh, elf segment at 7f34fd76c000(fff4) 
> requested but the memory is mapped already
>  16843 (a.out): Uhuuh, elf segment at 7f930ecc7000(fff4) 
> requested but the memory is mapped already
> 
> Complain only if -EEXIST, and use %px for printing the address.

Yes this is better. But...

[...]
> - if ((type & MAP_FIXED_NOREPLACE) && BAD_ADDR(map_addr))
> - pr_info("%d (%s): Uhuuh, elf segment at %p requested but the 
> memory is mapped already\n",
> - task_pid_nr(current), current->comm,
> - (void *)addr);
> + if ((type & MAP_FIXED_NOREPLACE) && map_addr == -EEXIST)

... please use PTR_ERR(map_addr) == -EEXIST

then you can add 
Acked-by: Michal Hocko 

> + pr_info("%d (%s): Uhuuh, elf segment at %px requested but the 
> memory is mapped already\n",
> + task_pid_nr(current), current->comm, (void *)addr);
>  
>   return(map_addr);
>  }
> -- 
> 1.8.3.1

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Tetsuo Handa]

Michal Hocko wrote:
> > Don't complain if IS_ERR_VALUE(),
> 
> this is simply wrong. We do want to warn on the failure because this is
> when the actual clash happens. We should just warn on EEXIST.

>From 25442cdd31aa5cc8522923a0153a77dfd2ebc832 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa 
Date: Wed, 18 Apr 2018 20:38:15 +0900
Subject: [PATCH] fs, elf: don't complain MAP_FIXED_NOREPLACE unless -EEXIST
 error.

Commit 4ed28639519c7bad ("fs, elf: drop MAP_FIXED usage from elf_map") is
printing spurious messages under memory pressure due to map_addr == -ENOMEM.

 9794 (a.out): Uhuuh, elf segment at 7f2e34738000(fff4) 
requested but the memory is mapped already
 14104 (a.out): Uhuuh, elf segment at 7f34fd76c000(fff4) 
requested but the memory is mapped already
 16843 (a.out): Uhuuh, elf segment at 7f930ecc7000(fff4) 
requested but the memory is mapped already

Complain only if -EEXIST, and use %px for printing the address.

Signed-off-by: Tetsuo Handa 
Cc: Michal Hocko 
Cc: Andrei Vagin 
Cc: Khalid Aziz 
Cc: Michael Ellerman 
Cc: Kees Cook 
Cc: Abdul Haleem 
Cc: Joel Stanley 
Cc: Anshuman Khandual 
---
 fs/binfmt_elf.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 41e0418..96615d9 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -377,10 +377,9 @@ static unsigned long elf_map(struct file *filep, unsigned 
long addr,
} else
map_addr = vm_mmap(filep, addr, size, prot, type, off);
 
-   if ((type & MAP_FIXED_NOREPLACE) && BAD_ADDR(map_addr))
-   pr_info("%d (%s): Uhuuh, elf segment at %p requested but the 
memory is mapped already\n",
-   task_pid_nr(current), current->comm,
-   (void *)addr);
+   if ((type & MAP_FIXED_NOREPLACE) && map_addr == -EEXIST)
+   pr_info("%d (%s): Uhuuh, elf segment at %px requested but the 
memory is mapped already\n",
+   task_pid_nr(current), current->comm, (void *)addr);
 
return(map_addr);
 }
-- 
1.8.3.1

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Tetsuo Handa]

Michal Hocko wrote:
> > Don't complain if IS_ERR_VALUE(),
> 
> this is simply wrong. We do want to warn on the failure because this is
> when the actual clash happens. We should just warn on EEXIST.

>From 25442cdd31aa5cc8522923a0153a77dfd2ebc832 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa 
Date: Wed, 18 Apr 2018 20:38:15 +0900
Subject: [PATCH] fs, elf: don't complain MAP_FIXED_NOREPLACE unless -EEXIST
 error.

Commit 4ed28639519c7bad ("fs, elf: drop MAP_FIXED usage from elf_map") is
printing spurious messages under memory pressure due to map_addr == -ENOMEM.

 9794 (a.out): Uhuuh, elf segment at 7f2e34738000(fff4) 
requested but the memory is mapped already
 14104 (a.out): Uhuuh, elf segment at 7f34fd76c000(fff4) 
requested but the memory is mapped already
 16843 (a.out): Uhuuh, elf segment at 7f930ecc7000(fff4) 
requested but the memory is mapped already

Complain only if -EEXIST, and use %px for printing the address.

Signed-off-by: Tetsuo Handa 
Cc: Michal Hocko 
Cc: Andrei Vagin 
Cc: Khalid Aziz 
Cc: Michael Ellerman 
Cc: Kees Cook 
Cc: Abdul Haleem 
Cc: Joel Stanley 
Cc: Anshuman Khandual 
---
 fs/binfmt_elf.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 41e0418..96615d9 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -377,10 +377,9 @@ static unsigned long elf_map(struct file *filep, unsigned 
long addr,
} else
map_addr = vm_mmap(filep, addr, size, prot, type, off);
 
-   if ((type & MAP_FIXED_NOREPLACE) && BAD_ADDR(map_addr))
-   pr_info("%d (%s): Uhuuh, elf segment at %p requested but the 
memory is mapped already\n",
-   task_pid_nr(current), current->comm,
-   (void *)addr);
+   if ((type & MAP_FIXED_NOREPLACE) && map_addr == -EEXIST)
+   pr_info("%d (%s): Uhuuh, elf segment at %px requested but the 
memory is mapped already\n",
+   task_pid_nr(current), current->comm, (void *)addr);
 
return(map_addr);
 }
-- 
1.8.3.1

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Michal Hocko]

On Wed 18-04-18 19:51:05, Tetsuo Handa wrote:
> >From 0ba20dcbbc40b703413c9a6907a77968b087811b Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa 
> Date: Wed, 18 Apr 2018 15:31:48 +0900
> Subject: [PATCH] fs, elf: don't complain MAP_FIXED_NOREPLACE if mapping
>  failed.
> 
> Commit 4ed28639519c7bad ("fs, elf: drop MAP_FIXED usage from elf_map") is
> printing spurious messages under memory pressure due to map_addr == -ENOMEM.
> 
>  9794 (a.out): Uhuuh, elf segment at 7f2e34738000(fff4) 
> requested but the memory is mapped already
>  14104 (a.out): Uhuuh, elf segment at 7f34fd76c000(fff4) 
> requested but the memory is mapped already
>  16843 (a.out): Uhuuh, elf segment at 7f930ecc7000(fff4) 
> requested but the memory is mapped already

Hmm this is ENOMEM.

> Don't complain if IS_ERR_VALUE(),

this is simply wrong. We do want to warn on the failure because this is
when the actual clash happens. We should just warn on EEXIST.

> and use %px for printing the address.
> 
> Signed-off-by: Tetsuo Handa 
> Cc: Michal Hocko 
> Cc: Andrei Vagin 
> Cc: Khalid Aziz 
> Cc: Michael Ellerman 
> Cc: Kees Cook 
> Cc: Abdul Haleem 
> Cc: Joel Stanley 
> Cc: Anshuman Khandual 
> ---
>  fs/binfmt_elf.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 41e0418..559d35b 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -377,10 +377,10 @@ static unsigned long elf_map(struct file *filep, 
> unsigned long addr,
>   } else
>   map_addr = vm_mmap(filep, addr, size, prot, type, off);
>  
> - if ((type & MAP_FIXED_NOREPLACE) && BAD_ADDR(map_addr))
> - pr_info("%d (%s): Uhuuh, elf segment at %p requested but the 
> memory is mapped already\n",
> - task_pid_nr(current), current->comm,
> - (void *)addr);
> + if ((type & MAP_FIXED_NOREPLACE) && BAD_ADDR(map_addr) &&
> + !IS_ERR_VALUE(map_addr))
> + pr_info("%d (%s): Uhuuh, elf segment at %px requested but the 
> memory is mapped already\n",
> + task_pid_nr(current), current->comm, (void *)addr);
>  
>   return(map_addr);
>  }
> -- 
> 1.8.3.1
> 
> 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Michal Hocko]

On Wed 18-04-18 19:51:05, Tetsuo Handa wrote:
> >From 0ba20dcbbc40b703413c9a6907a77968b087811b Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa 
> Date: Wed, 18 Apr 2018 15:31:48 +0900
> Subject: [PATCH] fs, elf: don't complain MAP_FIXED_NOREPLACE if mapping
>  failed.
> 
> Commit 4ed28639519c7bad ("fs, elf: drop MAP_FIXED usage from elf_map") is
> printing spurious messages under memory pressure due to map_addr == -ENOMEM.
> 
>  9794 (a.out): Uhuuh, elf segment at 7f2e34738000(fff4) 
> requested but the memory is mapped already
>  14104 (a.out): Uhuuh, elf segment at 7f34fd76c000(fff4) 
> requested but the memory is mapped already
>  16843 (a.out): Uhuuh, elf segment at 7f930ecc7000(fff4) 
> requested but the memory is mapped already

Hmm this is ENOMEM.

> Don't complain if IS_ERR_VALUE(),

this is simply wrong. We do want to warn on the failure because this is
when the actual clash happens. We should just warn on EEXIST.

> and use %px for printing the address.
> 
> Signed-off-by: Tetsuo Handa 
> Cc: Michal Hocko 
> Cc: Andrei Vagin 
> Cc: Khalid Aziz 
> Cc: Michael Ellerman 
> Cc: Kees Cook 
> Cc: Abdul Haleem 
> Cc: Joel Stanley 
> Cc: Anshuman Khandual 
> ---
>  fs/binfmt_elf.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 41e0418..559d35b 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -377,10 +377,10 @@ static unsigned long elf_map(struct file *filep, 
> unsigned long addr,
>   } else
>   map_addr = vm_mmap(filep, addr, size, prot, type, off);
>  
> - if ((type & MAP_FIXED_NOREPLACE) && BAD_ADDR(map_addr))
> - pr_info("%d (%s): Uhuuh, elf segment at %p requested but the 
> memory is mapped already\n",
> - task_pid_nr(current), current->comm,
> - (void *)addr);
> + if ((type & MAP_FIXED_NOREPLACE) && BAD_ADDR(map_addr) &&
> + !IS_ERR_VALUE(map_addr))
> + pr_info("%d (%s): Uhuuh, elf segment at %px requested but the 
> memory is mapped already\n",
> + task_pid_nr(current), current->comm, (void *)addr);
>  
>   return(map_addr);
>  }
> -- 
> 1.8.3.1
> 
> 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Tetsuo Handa]

>From 0ba20dcbbc40b703413c9a6907a77968b087811b Mon Sep 17 00:00:00 2001
From: Tetsuo Handa 
Date: Wed, 18 Apr 2018 15:31:48 +0900
Subject: [PATCH] fs, elf: don't complain MAP_FIXED_NOREPLACE if mapping
 failed.

Commit 4ed28639519c7bad ("fs, elf: drop MAP_FIXED usage from elf_map") is
printing spurious messages under memory pressure due to map_addr == -ENOMEM.

 9794 (a.out): Uhuuh, elf segment at 7f2e34738000(fff4) 
requested but the memory is mapped already
 14104 (a.out): Uhuuh, elf segment at 7f34fd76c000(fff4) 
requested but the memory is mapped already
 16843 (a.out): Uhuuh, elf segment at 7f930ecc7000(fff4) 
requested but the memory is mapped already

Don't complain if IS_ERR_VALUE(), and use %px for printing the address.

Signed-off-by: Tetsuo Handa 
Cc: Michal Hocko 
Cc: Andrei Vagin 
Cc: Khalid Aziz 
Cc: Michael Ellerman 
Cc: Kees Cook 
Cc: Abdul Haleem 
Cc: Joel Stanley 
Cc: Anshuman Khandual 
---
 fs/binfmt_elf.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 41e0418..559d35b 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -377,10 +377,10 @@ static unsigned long elf_map(struct file *filep, unsigned 
long addr,
} else
map_addr = vm_mmap(filep, addr, size, prot, type, off);
 
-   if ((type & MAP_FIXED_NOREPLACE) && BAD_ADDR(map_addr))
-   pr_info("%d (%s): Uhuuh, elf segment at %p requested but the 
memory is mapped already\n",
-   task_pid_nr(current), current->comm,
-   (void *)addr);
+   if ((type & MAP_FIXED_NOREPLACE) && BAD_ADDR(map_addr) &&
+   !IS_ERR_VALUE(map_addr))
+   pr_info("%d (%s): Uhuuh, elf segment at %px requested but the 
memory is mapped already\n",
+   task_pid_nr(current), current->comm, (void *)addr);
 
return(map_addr);
 }
-- 
1.8.3.1

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Tetsuo Handa]

>From 0ba20dcbbc40b703413c9a6907a77968b087811b Mon Sep 17 00:00:00 2001
From: Tetsuo Handa 
Date: Wed, 18 Apr 2018 15:31:48 +0900
Subject: [PATCH] fs, elf: don't complain MAP_FIXED_NOREPLACE if mapping
 failed.

Commit 4ed28639519c7bad ("fs, elf: drop MAP_FIXED usage from elf_map") is
printing spurious messages under memory pressure due to map_addr == -ENOMEM.

 9794 (a.out): Uhuuh, elf segment at 7f2e34738000(fff4) 
requested but the memory is mapped already
 14104 (a.out): Uhuuh, elf segment at 7f34fd76c000(fff4) 
requested but the memory is mapped already
 16843 (a.out): Uhuuh, elf segment at 7f930ecc7000(fff4) 
requested but the memory is mapped already

Don't complain if IS_ERR_VALUE(), and use %px for printing the address.

Signed-off-by: Tetsuo Handa 
Cc: Michal Hocko 
Cc: Andrei Vagin 
Cc: Khalid Aziz 
Cc: Michael Ellerman 
Cc: Kees Cook 
Cc: Abdul Haleem 
Cc: Joel Stanley 
Cc: Anshuman Khandual 
---
 fs/binfmt_elf.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 41e0418..559d35b 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -377,10 +377,10 @@ static unsigned long elf_map(struct file *filep, unsigned 
long addr,
} else
map_addr = vm_mmap(filep, addr, size, prot, type, off);
 
-   if ((type & MAP_FIXED_NOREPLACE) && BAD_ADDR(map_addr))
-   pr_info("%d (%s): Uhuuh, elf segment at %p requested but the 
memory is mapped already\n",
-   task_pid_nr(current), current->comm,
-   (void *)addr);
+   if ((type & MAP_FIXED_NOREPLACE) && BAD_ADDR(map_addr) &&
+   !IS_ERR_VALUE(map_addr))
+   pr_info("%d (%s): Uhuuh, elf segment at %px requested but the 
memory is mapped already\n",
+   task_pid_nr(current), current->comm, (void *)addr);
 
return(map_addr);
 }
-- 
1.8.3.1

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Khalid Aziz]

On 11/29/2017 07:42 AM, Michal Hocko wrote:

From: Michal Hocko 

Both load_elf_interp and load_elf_binary rely on elf_map to map segments
on a controlled address and they use MAP_FIXED to enforce that. This is
however dangerous thing prone to silent data corruption which can be
even exploitable. Let's take CVE-2017-1000253 as an example. At the time
(before eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE"))
ELF_ET_DYN_BASE was at TASK_SIZE / 3 * 2 which is not that far away from
the stack top on 32b (legacy) memory layout (only 1GB away). Therefore
we could end up mapping over the existing stack with some luck.

The issue has been fixed since then (a87938b2e246 ("fs/binfmt_elf.c:
fix bug in loading of PIE binaries")), ELF_ET_DYN_BASE moved moved much
further from the stack (eab09532d400 and later by c715b72c1ba4 ("mm:
revert x86_64 and arm64 ELF_ET_DYN_BASE base changes")) and excessive
stack consumption early during execve fully stopped by da029c11e6b1
("exec: Limit arg stack to at most 75% of _STK_LIM"). So we should be
safe and any attack should be impractical. On the other hand this is
just too subtle assumption so it can break quite easily and hard to
spot.

I believe that the MAP_FIXED usage in load_elf_binary (et. al) is still
fundamentally dangerous. Moreover it shouldn't be even needed. We are
at the early process stage and so there shouldn't be unrelated mappings
(except for stack and loader) existing so mmap for a given address
should succeed even without MAP_FIXED. Something is terribly wrong if
this is not the case and we should rather fail than silently corrupt the
underlying mapping.

Address this issue by changing MAP_FIXED to the newly added
MAP_FIXED_SAFE. This will mean that mmap will fail if there is an
existing mapping clashing with the requested one without clobbering it.

Cc: Abdul Haleem 
Cc: Joel Stanley 
Acked-by: Kees Cook 
Signed-off-by: Michal Hocko 
---


Reviewed-by: Khalid Aziz 

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Khalid Aziz]

On 11/29/2017 07:42 AM, Michal Hocko wrote:

From: Michal Hocko 

Both load_elf_interp and load_elf_binary rely on elf_map to map segments
on a controlled address and they use MAP_FIXED to enforce that. This is
however dangerous thing prone to silent data corruption which can be
even exploitable. Let's take CVE-2017-1000253 as an example. At the time
(before eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE"))
ELF_ET_DYN_BASE was at TASK_SIZE / 3 * 2 which is not that far away from
the stack top on 32b (legacy) memory layout (only 1GB away). Therefore
we could end up mapping over the existing stack with some luck.

The issue has been fixed since then (a87938b2e246 ("fs/binfmt_elf.c:
fix bug in loading of PIE binaries")), ELF_ET_DYN_BASE moved moved much
further from the stack (eab09532d400 and later by c715b72c1ba4 ("mm:
revert x86_64 and arm64 ELF_ET_DYN_BASE base changes")) and excessive
stack consumption early during execve fully stopped by da029c11e6b1
("exec: Limit arg stack to at most 75% of _STK_LIM"). So we should be
safe and any attack should be impractical. On the other hand this is
just too subtle assumption so it can break quite easily and hard to
spot.

I believe that the MAP_FIXED usage in load_elf_binary (et. al) is still
fundamentally dangerous. Moreover it shouldn't be even needed. We are
at the early process stage and so there shouldn't be unrelated mappings
(except for stack and loader) existing so mmap for a given address
should succeed even without MAP_FIXED. Something is terribly wrong if
this is not the case and we should rather fail than silently corrupt the
underlying mapping.

Address this issue by changing MAP_FIXED to the newly added
MAP_FIXED_SAFE. This will mean that mmap will fail if there is an
existing mapping clashing with the requested one without clobbering it.

Cc: Abdul Haleem 
Cc: Joel Stanley 
Acked-by: Kees Cook 
Signed-off-by: Michal Hocko 
---


Reviewed-by: Khalid Aziz 

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Kees Cook]

On Thu, Nov 16, 2017 at 2:19 AM, Michal Hocko  wrote:
> From: Michal Hocko 
>
> Both load_elf_interp and load_elf_binary rely on elf_map to map segments
> on a controlled address and they use MAP_FIXED to enforce that. This is
> however dangerous thing prone to silent data corruption which can be
> even exploitable. Let's take CVE-2017-1000253 as an example. At the time
> (before eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE"))
> ELF_ET_DYN_BASE was at TASK_SIZE / 3 * 2 which is not that far away from
> the stack top on 32b (legacy) memory layout (only 1GB away). Therefore
> we could end up mapping over the existing stack with some luck.
>
> The issue has been fixed since then (a87938b2e246 ("fs/binfmt_elf.c:
> fix bug in loading of PIE binaries")), ELF_ET_DYN_BASE moved moved much
> further from the stack (eab09532d400 and later by c715b72c1ba4 ("mm:
> revert x86_64 and arm64 ELF_ET_DYN_BASE base changes")) and excessive
> stack consumption early during execve fully stopped by da029c11e6b1
> ("exec: Limit arg stack to at most 75% of _STK_LIM"). So we should be
> safe and any attack should be impractical. On the other hand this is
> just too subtle assumption so it can break quite easily and hard to
> spot.
>
> I believe that the MAP_FIXED usage in load_elf_binary (et. al) is still
> fundamentally dangerous. Moreover it shouldn't be even needed. We are
> at the early process stage and so there shouldn't be unrelated mappings
> (except for stack and loader) existing so mmap for a given address
> should succeed even without MAP_FIXED. Something is terribly wrong if
> this is not the case and we should rather fail than silently corrupt the
> underlying mapping.
>
> Address this issue by changing MAP_FIXED to the newly added
> MAP_FIXED_SAFE. This will mean that mmap will fail if there is an
> existing mapping clashing with the requested one without clobbering it.
>
> Cc: Abdul Haleem 
> Cc: Joel Stanley 
> Cc: Kees Cook 
> Signed-off-by: Michal Hocko 

Once (if?) the name gets settled, this looks good to me:

Acked-by: Kees Cook 

-Kees

> ---
>  arch/metag/kernel/process.c |  6 +-
>  fs/binfmt_elf.c | 12 
>  2 files changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/arch/metag/kernel/process.c b/arch/metag/kernel/process.c
> index c4606ce743d2..2286140e54e0 100644
> --- a/arch/metag/kernel/process.c
> +++ b/arch/metag/kernel/process.c
> @@ -398,7 +398,7 @@ unsigned long __metag_elf_map(struct file *filep, 
> unsigned long addr,
> tcm_tag = tcm_lookup_tag(addr);
>
> if (tcm_tag != TCM_INVALID_TAG)
> -   type &= ~MAP_FIXED;
> +   type &= ~(MAP_FIXED | MAP_FIXED_SAFE);
>
> /*
> * total_size is the size of the ELF (interpreter) image.
> @@ -416,6 +416,10 @@ unsigned long __metag_elf_map(struct file *filep, 
> unsigned long addr,
> } else
> map_addr = vm_mmap(filep, addr, size, prot, type, off);
>
> +   if ((type & MAP_FIXED_SAFE) && BAD_ADDR(map_addr))
> +   pr_info("%d (%s): Uhuuh, elf segement at %p requested but the 
> memory is mapped already\n",
> +   task_pid_nr(current), tsk->comm, (void*)addr);
> +
> if (!BAD_ADDR(map_addr) && tcm_tag != TCM_INVALID_TAG) {
> struct tcm_allocation *tcm;
> unsigned long tcm_addr;
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 6466153f2bf0..12b21942ccde 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -372,6 +372,10 @@ static unsigned long elf_map(struct file *filep, 
> unsigned long addr,
> } else
> map_addr = vm_mmap(filep, addr, size, prot, type, off);
>
> +   if ((type & MAP_FIXED_SAFE) && BAD_ADDR(map_addr))
> +   pr_info("%d (%s): Uhuuh, elf segement at %p requested but the 
> memory is mapped already\n",
> +   task_pid_nr(current), current->comm, 
> (void*)addr);
> +
> return(map_addr);
>  }
>
> @@ -569,7 +573,7 @@ static unsigned long load_elf_interp(struct elfhdr 
> *interp_elf_ex,
> elf_prot |= PROT_EXEC;
> vaddr = eppnt->p_vaddr;
> if (interp_elf_ex->e_type == ET_EXEC || load_addr_set)
> -   elf_type |= MAP_FIXED;
> +   elf_type |= MAP_FIXED_SAFE;
> else if (no_base && interp_elf_ex->e_type == ET_DYN)
> load_addr = -vaddr;
>
> @@ -929,7 +933,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>  * the ET_DYN load_addr calculations, proceed normally.
>  */
> if (loc->elf_ex.e_type == ET_EXEC || load_addr_set) {
> -   elf_flags |= MAP_FIXED;
> +

Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map

[Kees Cook]

On Thu, Nov 16, 2017 at 2:19 AM, Michal Hocko  wrote:
> From: Michal Hocko 
>
> Both load_elf_interp and load_elf_binary rely on elf_map to map segments
> on a controlled address and they use MAP_FIXED to enforce that. This is
> however dangerous thing prone to silent data corruption which can be
> even exploitable. Let's take CVE-2017-1000253 as an example. At the time
> (before eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE"))
> ELF_ET_DYN_BASE was at TASK_SIZE / 3 * 2 which is not that far away from
> the stack top on 32b (legacy) memory layout (only 1GB away). Therefore
> we could end up mapping over the existing stack with some luck.
>
> The issue has been fixed since then (a87938b2e246 ("fs/binfmt_elf.c:
> fix bug in loading of PIE binaries")), ELF_ET_DYN_BASE moved moved much
> further from the stack (eab09532d400 and later by c715b72c1ba4 ("mm:
> revert x86_64 and arm64 ELF_ET_DYN_BASE base changes")) and excessive
> stack consumption early during execve fully stopped by da029c11e6b1
> ("exec: Limit arg stack to at most 75% of _STK_LIM"). So we should be
> safe and any attack should be impractical. On the other hand this is
> just too subtle assumption so it can break quite easily and hard to
> spot.
>
> I believe that the MAP_FIXED usage in load_elf_binary (et. al) is still
> fundamentally dangerous. Moreover it shouldn't be even needed. We are
> at the early process stage and so there shouldn't be unrelated mappings
> (except for stack and loader) existing so mmap for a given address
> should succeed even without MAP_FIXED. Something is terribly wrong if
> this is not the case and we should rather fail than silently corrupt the
> underlying mapping.
>
> Address this issue by changing MAP_FIXED to the newly added
> MAP_FIXED_SAFE. This will mean that mmap will fail if there is an
> existing mapping clashing with the requested one without clobbering it.
>
> Cc: Abdul Haleem 
> Cc: Joel Stanley 
> Cc: Kees Cook 
> Signed-off-by: Michal Hocko 

Once (if?) the name gets settled, this looks good to me:

Acked-by: Kees Cook 

-Kees

> ---
>  arch/metag/kernel/process.c |  6 +-
>  fs/binfmt_elf.c | 12 
>  2 files changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/arch/metag/kernel/process.c b/arch/metag/kernel/process.c
> index c4606ce743d2..2286140e54e0 100644
> --- a/arch/metag/kernel/process.c
> +++ b/arch/metag/kernel/process.c
> @@ -398,7 +398,7 @@ unsigned long __metag_elf_map(struct file *filep, 
> unsigned long addr,
> tcm_tag = tcm_lookup_tag(addr);
>
> if (tcm_tag != TCM_INVALID_TAG)
> -   type &= ~MAP_FIXED;
> +   type &= ~(MAP_FIXED | MAP_FIXED_SAFE);
>
> /*
> * total_size is the size of the ELF (interpreter) image.
> @@ -416,6 +416,10 @@ unsigned long __metag_elf_map(struct file *filep, 
> unsigned long addr,
> } else
> map_addr = vm_mmap(filep, addr, size, prot, type, off);
>
> +   if ((type & MAP_FIXED_SAFE) && BAD_ADDR(map_addr))
> +   pr_info("%d (%s): Uhuuh, elf segement at %p requested but the 
> memory is mapped already\n",
> +   task_pid_nr(current), tsk->comm, (void*)addr);
> +
> if (!BAD_ADDR(map_addr) && tcm_tag != TCM_INVALID_TAG) {
> struct tcm_allocation *tcm;
> unsigned long tcm_addr;
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 6466153f2bf0..12b21942ccde 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -372,6 +372,10 @@ static unsigned long elf_map(struct file *filep, 
> unsigned long addr,
> } else
> map_addr = vm_mmap(filep, addr, size, prot, type, off);
>
> +   if ((type & MAP_FIXED_SAFE) && BAD_ADDR(map_addr))
> +   pr_info("%d (%s): Uhuuh, elf segement at %p requested but the 
> memory is mapped already\n",
> +   task_pid_nr(current), current->comm, 
> (void*)addr);
> +
> return(map_addr);
>  }
>
> @@ -569,7 +573,7 @@ static unsigned long load_elf_interp(struct elfhdr 
> *interp_elf_ex,
> elf_prot |= PROT_EXEC;
> vaddr = eppnt->p_vaddr;
> if (interp_elf_ex->e_type == ET_EXEC || load_addr_set)
> -   elf_type |= MAP_FIXED;
> +   elf_type |= MAP_FIXED_SAFE;
> else if (no_base && interp_elf_ex->e_type == ET_DYN)
> load_addr = -vaddr;
>
> @@ -929,7 +933,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>  * the ET_DYN load_addr calculations, proceed normally.
>  */
> if (loc->elf_ex.e_type == ET_EXEC || load_addr_set) {
> -   elf_flags |= MAP_FIXED;
> +   elf_flags |= MAP_FIXED_SAFE;
> } else if (loc->elf_ex.e_type == ET_DYN) {
> /*
>