linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mike Kravetz <mike.kravetz@oracle.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
	libhugetlbfs@googlegroups.com
Subject: Re: [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map
Date: Wed, 30 May 2018 17:51:15 -0700	[thread overview]
Message-ID: <1f6be96b-12ac-9a03-df90-386dab02369d@oracle.com> (raw)
In-Reply-To: <20180530162501.GB15278@dhcp22.suse.cz>

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  = 9000000
[   38.918119]     index 4 p_paddr  = 9000000
[   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

  reply	other threads:[~2018-05-31  0:51 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-29 14:42 [PATCH 0/2] mm: introduce MAP_FIXED_SAFE Michal Hocko
2017-11-29 14:42 ` [PATCH 1/2] " Michal Hocko
2017-12-06  5:15   ` Michael Ellerman
2017-12-06  9:27     ` Michal Hocko
2017-12-06 10:02       ` Michal Hocko
2017-12-07 12:07   ` Pavel Machek
2017-11-29 14:42 ` [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map Michal Hocko
2017-11-29 17:45   ` Khalid Aziz
2018-05-29 22:21     ` Mike Kravetz
2018-05-30  8:02       ` Michal Hocko
2018-05-30 15:00         ` Mike Kravetz
2018-05-30 16:25           ` Michal Hocko
2018-05-31  0:51             ` Mike Kravetz [this message]
2018-05-31  9:24               ` Michal Hocko
2018-05-31 21:46                 ` Mike Kravetz
2017-11-29 14:45 ` [PATCH] mmap.2: document new MAP_FIXED_SAFE flag Michal Hocko
2017-11-30  3:16   ` John Hubbard
2017-11-30  8:23     ` Michal Hocko
2017-11-30  8:24   ` [PATCH v2] " Michal Hocko
2017-11-30 18:31     ` John Hubbard
2017-11-30 18:39       ` Michal Hocko
2017-11-29 15:13 ` [PATCH 0/2] mm: introduce MAP_FIXED_SAFE Rasmus Villemoes
2017-11-29 15:50   ` Michal Hocko
2017-11-29 22:15   ` Kees Cook
2017-11-29 22:12 ` Kees Cook
2017-11-29 22:25 ` Kees Cook
2017-11-30  6:58   ` Michal Hocko
2017-12-01 15:26     ` Cyril Hrubis
2017-12-06  4:51       ` Michael Ellerman
2017-12-06  4:54         ` Matthew Wilcox
2017-12-06  7:03           ` Matthew Wilcox
2017-12-06  7:33             ` John Hubbard
2017-12-06  7:35               ` Florian Weimer
2017-12-06  8:06                 ` John Hubbard
2017-12-06  8:54                   ` Florian Weimer
2017-12-07  5:46             ` Michael Ellerman
2017-12-07 19:14               ` Kees Cook
2017-12-07 19:57                 ` Matthew Wilcox
2017-12-08  8:33                   ` Michal Hocko
2017-12-08 20:13                     ` Kees Cook
2017-12-08 20:57                       ` Matthew Wilcox
2017-12-08 11:08                   ` Michael Ellerman
2017-12-08 14:27                     ` Pavel Machek
2017-12-08 20:31                       ` Cyril Hrubis
2017-12-08 20:47                       ` Florian Weimer
2017-12-08 14:33                     ` David Laight
2017-12-06  4:50     ` Michael Ellerman
2017-12-06  7:33       ` Rasmus Villemoes
2017-12-06  9:08         ` Michal Hocko
2017-12-07  0:19           ` Kees Cook
2017-12-07  1:08             ` John Hubbard
  -- strict thread matches above, loose matches on Subject: below --
2017-12-13  9:25 [PATCH v2 " Michal Hocko
2017-12-13  9:25 ` [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map Michal Hocko
2018-04-18 10:51   ` Tetsuo Handa
2018-04-18 11:33     ` Michal Hocko
2018-04-18 11:43       ` Tetsuo Handa
2018-04-18 11:55         ` Michal Hocko
2017-11-16 10:18 Michal Hocko
2017-11-16 10:19 ` [PATCH 2/2] fs, elf: drop MAP_FIXED usage from elf_map Michal Hocko
2017-11-17  0:30   ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1f6be96b-12ac-9a03-df90-386dab02369d@oracle.com \
    --to=mike.kravetz@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=libhugetlbfs@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).