On Tue 09-01-18 17:18:38, Anshuman Khandual wrote:

On 01/09/2018 03:42 AM, Michael Ellerman wrote:

quoted

Anshuman Khandual [off-list ref] writes:

quoted

On 01/07/2018 04:56 PM, Michael Ellerman wrote:

quoted

Michal Hocko [off-list ref] writes:

quoted

On Sun 07-01-18 12:19:32, Anshuman Khandual wrote:

quoted

On 01/05/2018 02:16 PM, Michal Hocko wrote:

[...]

quoted

quoted

Could you give us more information about the failure please. Debugging
patch from http://lkml.kernel.org/r/20171218091302.GL16951@dhcp22.suse.cz
should help to see what is the clashing VMA.

Seems like its re-requesting the same mapping again.

It always seems to be the same mapping which is a bit strange as we
have multiple binaries here. Are these binaries any special? Does this
happen to all bianries (except for init which has obviously started
successfully)? Could you add an additional debugging (at the do_mmap
layer) to see who is requesting the mapping for the first time?

quoted

[   23.423642] 9148 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   23.423706] requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon

I also find it a bit unexpected that this is an anonymous mapping
because the elf loader should always map a file backed one.

Anshuman what machine is this on, and what distro and toolchain is it running?

I don't see this on any of my machines, so I wonder if this is
toolchain/distro specific.

POWER9, RHEL 7.4, gcc (GCC) 4.8.5 20150623, GNU Make 3.82 etc.

So what does readelf -a of /bin/sed look like?

Please find here.

Did you manage to catch _who_ is requesting that anonymous mapping? Do
you need a help with the debugging patch?
-- 
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>