From: Michal Hocko <mhocko@kernel.org>
To: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
mm-commits@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-next@vger.kernel.org, sfr@canb.auug.org.au,
broonie@kernel.org, Kees Cook <keescook@chromium.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
Date: Thu, 1 Feb 2018 14:10:07 +0100 [thread overview]
Message-ID: <20180201131007.GJ21609@dhcp22.suse.cz> (raw)
In-Reply-To: <bfecda5e-ae8b-df91-0add-df6322b42a70@linux.vnet.ibm.com>
[CC Kees and Linus - for your background, we are talking about failures
http://lkml.kernel.org/r/20180107090229.GB24862@dhcp22.suse.cz
introduced by http://lkml.kernel.org/r/20171213092550.2774-3-mhocko@kernel.org
Debugging has shown that load_elf_binary tries to map elf segment over
an existing brk - see below.]
On Thu 01-02-18 08:43:34, Anshuman Khandual wrote:
[...]
> [ 9.295990] vma c000001fc8137c80 start 0000000010030000 end 0000000010040000
> next c000001fc81378c0 prev c000001fc8137680 mm c000001fc8108200
> prot 8000000000000104 anon_vma (null) vm_ops (null)
> pgoff 1003 file (null) private_data (null)
> flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
> [ 9.296351] CPU: 47 PID: 7537 Comm: sed Not tainted 4.14.0-00006-g4bd92fe-dirty #162
> [ 9.296450] Call Trace:
> [ 9.296482] [c000001fc70db9b0] [c000000000b180e0] dump_stack+0xb0/0xf0 (unreliable)
> [ 9.296588] [c000001fc70db9f0] [c0000000002db0b8] do_brk_flags+0x2d8/0x440
> [ 9.296674] [c000001fc70dbac0] [c0000000002db4d0] vm_brk_flags+0x80/0x130
> [ 9.296751] [c000001fc70dbb20] [c0000000003d2998] set_brk+0x80/0xe8
> [ 9.296824] [c000001fc70dbb60] [c0000000003d2518] load_elf_binary+0x12f8/0x1580
> [ 9.296910] [c000001fc70dbc80] [c00000000035d9e0] search_binary_handler+0xd0/0x270
> [ 9.296999] [c000001fc70dbd10] [c00000000035f938] do_execveat_common.isra.31+0x658/0x890
> [ 9.297089] [c000001fc70dbdf0] [c00000000035ff80] SyS_execve+0x40/0x50
> [ 9.297162] [c000001fc70dbe30] [c00000000000b220] system_call+0x58/0x6c
>
> But coming back to when it failed with MAP_FIXED_NOREPLACE, looking into ELF
> section details (readelf -aW /usr/bin/sed), there was a PT_LOAD segment with
> p_memsz > p_filesz which might be causing set_brk() to be called.
>
>
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> ...
> LOAD 0x020328 0x0000000010030328 0x0000000010030328 0x000384 0x0094a0 RW 0x10000
>
> which can be confirmed by just dumping elf_brk/elf_bss for this particular
> instance. (elf_brk > elf_bss)
Hmm, interesting. So the above is not a regular brk. The check has been
added in 2001 by "v2.4.10.1 -> v2.4.10.2" but the changelog is not
revealing at all.
Btw. my /bin/ls also has MemSiz>FileSiz
LOAD 0x01ade0 0x000000000061ade0 0x000000000061ade0 0x00079c 0x001520 RW 0x200000
113: 000000000061b57c 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
and do not see any problem. So this is more likely a problem of elf_brk
being placed at a wrong address. But I am desperately lost in this code
so I might be completely off.
> $dmesg | grep elf_brk
> [ 9.571192] elf_brk 10030328 elf_bss 10030000
Hmm these are on the same page. Is this really expected?
> static int load_elf_binary(struct linux_binprm *bprm)
> ---------------------
>
> if (unlikely (elf_brk > elf_bss)) {
> unsigned long nbyte;
>
> /* There was a PT_LOAD segment with p_memsz > p_filesz
> before this one. Map anonymous pages, if needed,
> and clear the area. */
> retval = set_brk(elf_bss + load_bias,
> elf_brk + load_bias,
> bss_prot);
>
>
> ---------------------
> So is not there a chance that subsequent file mapping might be overlapping
> with these anon mappings ? I mean may be thats how ELF loading might be
> happening right now.
I will study the code more but it would be really great if
somebody more familiar with this area could help me out a
bit. Why do we add this brk at all and why it doesn't matter that
we map over it by a real file mapping. As per previous email
http://lkml.kernel.org/r/20180130094205.GS21609@dhcp22.suse.cz there
will be a new brk established later.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2018-02-01 13:10 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-05 0:20 mmotm 2018-01-04-16-19 uploaded akpm
2018-01-05 6:43 ` Anshuman Khandual
2018-01-05 8:46 ` Michal Hocko
2018-01-07 6:49 ` Anshuman Khandual
2018-01-07 9:02 ` ppc elf_map breakage with MAP_FIXED_NOREPLACE (was: Re: mmotm 2018-01-04-16-19 uploaded) Michal Hocko
2018-01-07 11:26 ` Michael Ellerman
2018-01-08 3:02 ` ppc elf_map breakage with MAP_FIXED_NOREPLACE Anshuman Khandual
2018-01-08 22:12 ` Michael Ellerman
2018-01-09 11:48 ` Anshuman Khandual
2018-01-09 16:13 ` Michal Hocko
2018-01-11 10:08 ` Anshuman Khandual
2018-01-17 8:07 ` Michal Hocko
2018-01-23 11:25 ` Anshuman Khandual
2018-01-23 12:45 ` Michal Hocko
2018-01-23 15:58 ` Anshuman Khandual
2018-01-23 16:06 ` Michal Hocko
2018-01-24 5:09 ` Anshuman Khandual
2018-01-24 9:05 ` Michal Hocko
2018-01-26 12:34 ` Anshuman Khandual
2018-01-26 14:04 ` Michal Hocko
2018-01-29 2:47 ` Anshuman Khandual
2018-01-29 5:32 ` Anshuman Khandual
2018-01-29 13:22 ` Michal Hocko
2018-01-30 3:35 ` Michael Ellerman
2018-01-30 9:42 ` Michal Hocko
2018-01-31 5:05 ` Anshuman Khandual
2018-01-31 13:19 ` Michal Hocko
2018-02-01 3:13 ` Anshuman Khandual
2018-02-01 13:10 ` Michal Hocko [this message]
2018-02-01 13:40 ` Michal Hocko
2018-02-01 20:55 ` Kees Cook
2018-02-13 10:04 ` [RFC PATCH] elf: enforce MAP_FIXED on overlaying elf segments (was: Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE) Michal Hocko
2018-02-14 16:30 ` Khalid Aziz
2018-02-01 13:48 ` ppc elf_map breakage with MAP_FIXED_NOREPLACE Michal Hocko
2018-02-01 21:06 ` Kees Cook
2018-02-12 14:48 ` Michal Hocko
2018-02-13 1:02 ` Anshuman Khandual
2018-02-13 6:49 ` Anshuman Khandual
2018-02-13 10:00 ` Michal Hocko
2018-01-05 12:14 ` mmotm 2018-01-04-16-19 uploaded Michal Hocko
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=20180201131007.GJ21609@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=broonie@kernel.org \
--cc=keescook@chromium.org \
--cc=khandual@linux.vnet.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-next@vger.kernel.org \
--cc=mm-commits@vger.kernel.org \
--cc=mpe@ellerman.id.au \
--cc=sfr@canb.auug.org.au \
--cc=torvalds@linux-foundation.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).