From: Michal Hocko <mhocko@kernel.org>
To: Mike Kravetz <mike.kravetz@oracle.com>
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 18:25:01 +0200 [thread overview]
Message-ID: <20180530162501.GB15278@dhcp22.suse.cz> (raw)
In-Reply-To: <e7705544-04fe-c382-f6d0-48d0680b46f2@oracle.com>
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: 110 113
> >> * Skipped: 0 0
> >> * PASS: 105 111
> >> * 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: 110 113
> >> * Skipped: 0 0
> >> * PASS: 98 111
> >> * 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 00000000a731413b requested but the memory is mapped already
> [ 47.606991] 1372 (xB.linkhuge_nof): Uhuuh, elf segment at 00000000a731413b requested but the memory is mapped already
> [ 47.641351] 1376 (xB.linkhuge_nof): Uhuuh, elf segment at 00000000a731413b requested but the memory is mapped already
> [ 47.726138] 1384 (xB.linkhuge): Uhuuh, elf segment at 0000000090b9eaf6 requested but the memory is mapped already
> [ 47.773169] 1393 (xB.linkhuge): Uhuuh, elf segment at 0000000090b9eaf6 requested but the memory is mapped already
> [ 47.817788] 1402 (xB.linkhuge): Uhuuh, elf segment at 0000000090b9eaf6 requested but the memory is mapped already
> [ 47.857338] 1406 (xB.linkshare): Uhuuh, elf segment at 0000000018430471 requested but the memory is mapped already
> [ 47.956355] 1427 (xB.linkshare): Uhuuh, elf segment at 0000000018430471 requested but the memory is mapped already
> [ 48.054894] 1448 (xB.linkhuge): Uhuuh, elf segment at 0000000090b9eaf6 requested but the memory is mapped already
> [ 48.071221] 1451 (xB.linkhuge): Uhuuh, elf segment at 0000000090b9eaf6 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
next prev parent reply other threads:[~2018-05-30 16:25 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 [this message]
2018-05-31 0:51 ` Mike Kravetz
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=20180530162501.GB15278@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=libhugetlbfs@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
/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).