All of lore.kernel.org
 help / color / mirror / Atom feed
* mmotm 2018-01-04-16-19 uploaded
@ 2018-01-05  0:20 ` akpm
  0 siblings, 0 replies; 82+ messages in thread
From: akpm @ 2018-01-05  0:20 UTC (permalink / raw)
  To: mm-commits, linux-kernel, linux-mm, linux-fsdevel, linux-next,
	sfr, mhocko, broonie

The mm-of-the-moment snapshot 2018-01-04-16-19 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (4.x
or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE-yyyy-mm-dd-hh-mm-ss.  Both contain the string yyyy-mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/

To develop on top of mmotm git:

  $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  <make changes, commit>
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master <topic base> topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

	http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 4.15-rc6:
(patches marked "*" will be included in linux-next)

  origin.patch
  i-need-old-gcc.patch
* mm-check-pfn_valid-first-in-zero_resv_unavail.patch
* acct-fix-the-acct-needcheck-check-in-check_free_space.patch
* mm-mprotect-add-a-cond_resched-inside-change_pmd_range.patch
* kernel-exitc-export-abort-to-modules.patch
* provide-useful-debugging-information-for-vm_bug.patch
* zsmalloc-add-fsh-include.patch
* mm-sparsec-wrong-allocation-for-mem_section.patch
* userfaultfd-clear-the-vma-vm_userfaultfd_ctx-if-uffd_event_fork-fails.patch
* mailmap-update-mark-yaos-email-address.patch
* scripts-decodecode-fix-decoding-for-aarch64-arm64-instructions.patch
* mm-skip-hwpoisoned-pages-when-onlining-pages.patch
* mm-release-locked-page-in-do_swap_page.patch
* arm-arch-arm-include-asm-pageh-needs-personalityh.patch
* prctl-add-pr_et_pdeathsig_proc.patch
* scripts-decodecode-make-it-take-multiline-code-line.patch
* scripts-tags-change-find_other_sources-for-include-folders.patch
* ocfs2-dlm-clean-dead-code-up.patch
* ocfs2-cluster-neaten-a-member-of-o2net_msg_handler.patch
* ocfs2-give-an-obvious-tip-for-dismatch-cluster-names.patch
* ocfs2-cluster-close-a-race-that-fence-cant-be-triggered.patch
* ocfs2-using-the-ocfs2_xattr_root_size-macro-in-ocfs2_reflink_xattr_header.patch
* ocfs2-clean-dead-code-in-suballocc.patch
* ocfs2-return-erofs-to-mountocfs2-if-inode-block-is-invalid.patch
* ocfs2-get-rid-of-ocfs2_is_o2cb_active-function.patch
* ocfs2-move-some-definitions-to-header-file.patch
* ocfs2-fix-some-small-problems.patch
* ocfs2-add-kobject-for-online-file-check.patch
* ocfs2-add-duplicative-ino-number-check.patch
* ocfs2-add-ocfs2_try_rw_lock-and-ocfs2_try_inode_lock.patch
* ocfs2-add-ocfs2_overwrite_io-function.patch
* ocfs2-add-ocfs2_overwrite_io-function-v3.patch
* ocfs2-nowait-aio-support.patch
* ocfs2-add-trimfs-dlm-lock-resource.patch
* ocfs2-add-trimfs-lock-to-avoid-duplicated-trims-in-cluster.patch
* ocfs2-try-a-blocking-lock-before-return-aop_truncated_page.patch
* block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch
* dentry-fix-kmemcheck-splat-at-take_dentry_name_snapshot.patch
  mm.patch
* mm-terminate-shrink_slab-loop-if-signal-is-pending.patch
* mm-terminate-shrink_slab-loop-if-signal-is-pending-fix.patch
* mm-slab-make-calculate_alignment-function-static.patch
* mm-slab-remove-redundant-assignments-for-slab_state.patch
* include-linux-sched-mmh-uninline-mmdrop_async-etc.patch
* mm-kmemleak-remove-unused-hardirqh.patch
* zswap-same-filled-pages-handling.patch
* zswap-same-filled-pages-handling-v2.patch
* mm-relax-deferred-struct-page-requirements.patch
* mm-mempolicy-remove-redundant-check-in-get_nodes.patch
* mm-mempolicy-fix-the-check-of-nodemask-from-user.patch
* mm-mempolicy-add-nodes_empty-check-in-sysc_migrate_pages.patch
* mm-drop-hotplug-lock-from-lru_add_drain_all.patch
* mm-show-total-hugetlb-memory-consumption-in-proc-meminfo.patch
* mm-use-sc-priority-for-slab-shrink-targets.patch
* mm-mlock-vmscan-no-more-skipping-pagevecs.patch
* mmvmscan-mark-register_shrinker-as-__must_check.patch
* mm-split-deferred_init_range-into-initializing-and-freeing-parts.patch
* mm-split-deferred_init_range-into-initializing-and-freeing-parts-fix.patch
* mm-filemap-remove-include-of-hardirqh.patch
* mm-memcontrol-eliminate-raw-access-to-stat-and-event-counters.patch
* mm-memcontrol-implement-lruvec-stat-functions-on-top-of-each-other.patch
* mm-memcontrol-fix-excessive-complexity-in-memorystat-reporting.patch
* mm-memcontrol-fix-excessive-complexity-in-memorystat-reporting-fix.patch
* mm-page_owner-use-ptr_err_or_zero.patch
* mm-page_alloc-fix-comment-is-__get_free_pages.patch
* mm-do-not-stall-register_shrinker.patch
* mm-do-not-stall-register_shrinker-fix.patch
* selftest-vm-move-128tb-mmap-boundary-test-to-generic-directory.patch
* selftest-vm-move-128tb-mmap-boundary-test-to-generic-directory-fix.patch
* mm-use-vma_pages-helper.patch
* mm-remove-unused-pgdat_reclaimable_pages.patch
* list_lru-prefetch-neighboring-list-entries-before-acquiring-lock.patch
* list_lru-prefetch-neighboring-list-entries-before-acquiring-lock-fix.patch
* mm-oom-refactor-the-oom_kill_process-function.patch
* mm-implement-mem_cgroup_scan_tasks-for-the-root-memory-cgroup.patch
* mm-oom-cgroup-aware-oom-killer.patch
* mm-oom-cgroup-aware-oom-killer-fix.patch
* mm-oom-introduce-memoryoom_group.patch
* mm-oom-introduce-memoryoom_group-fix.patch
* mm-oom-add-cgroup-v2-mount-option-for-cgroup-aware-oom-killer.patch
* mm-oom-docs-describe-the-cgroup-aware-oom-killer.patch
* mm-oom-docs-describe-the-cgroup-aware-oom-killer-fix.patch
* cgroup-list-groupoom-in-cgroup-features.patch
* mm-hugetlb-drop-hugepages_treat_as_movable-sysctl.patch
* mm-memory_hotplug-remove-unnecesary-check-from-register_page_bootmem_info_section.patch
* mm-update-comment-describing-tlb_gather_mmu.patch
* proc-do-not-show-vmexe-bigger-than-total-executable-virtual-memory.patch
* mm-add-strictlimit-knob-v2.patch
* mm-memory_hotplug-remove-second-__nr_to_section-in-register_page_bootmem_info_section.patch
* mm-huge_memory-fix-comment-in-__split_huge_pmd_locked.patch
* mm-userfaultfd-thp-avoid-waiting-when-pmd-under-thp-migration.patch
* mm-page_alloc-dont-reserve-zone_highmem-for-zone_movable-request.patch
* mm-cma-manage-the-memory-of-the-cma-area-by-using-the-zone_movable.patch
* mm-cma-remove-alloc_cma.patch
* arm-cma-avoid-double-mapping-to-the-cma-area-if-config_highmem-=-y.patch
* mm-add-unmap_mapping_pages.patch
* get-7%-more-pages-in-a-pagevec.patch
* asm-generic-provide-generic_pmdp_establish.patch
* arc-use-generic_pmdp_establish-as-pmdp_establish.patch
* arm-mm-provide-pmdp_establish-helper.patch
* arm64-provide-pmdp_establish-helper.patch
* mips-use-generic_pmdp_establish-as-pmdp_establish.patch
* powerpc-mm-update-pmdp_invalidate-to-return-old-pmd-value.patch
* s390-mm-modify-pmdp_invalidate-to-return-old-value.patch
* sparc64-update-pmdp_invalidate-to-return-old-pmd-value.patch
* sparc64-update-pmdp_invalidate-to-return-old-pmd-value-fix.patch
* x86-mm-provide-pmdp_establish-helper.patch
* x86-mm-provide-pmdp_establish-helper-fix.patch
* mm-do-not-lose-dirty-and-access-bits-in-pmdp_invalidate.patch
* mm-use-updated-pmdp_invalidate-interface-to-track-dirty-accessed-bits.patch
* mm-thp-remove-pmd_huge_split_prepare.patch
* mm-introduce-map_fixed_safe.patch
* mm-introduce-map_fixed_safe-fix.patch
* fs-elf-drop-map_fixed-usage-from-elf_map.patch
* fs-elf-drop-map_fixed-usage-from-elf_map-fix.patch
* fs-elf-drop-map_fixed-usage-from-elf_map-checkpatch-fixes.patch
* mm-thp-use-down_read_trylock-in-khugepaged-to-avoid-long-block.patch
* mm-thp-use-down_read_trylock-in-khugepaged-to-avoid-long-block-fix.patch
* mm-thp-use-down_read_trylock-in-khugepaged-to-avoid-long-block-fix-2.patch
* mm-thp-use-down_read_trylock-in-khugepaged-to-avoid-long-block-fix-checkpatch-fixes.patch
* mm-mmu_notifier-annotate-mmu-notifiers-with-blockable-invalidate-callbacks.patch
* mm-mmu_notifier-annotate-mmu-notifiers-with-blockable-invalidate-callbacks-fix.patch
* mm-oom-avoid-reaping-only-for-mms-with-blockable-invalidate-callbacks.patch
* mm-zsmalloc-simplify-shrinker-init-destroy.patch
* mm-zsmalloc-simplify-shrinker-init-destroy-fix.patch
* mm-vmalloc-replace-opencoded-4-level-page-walkers.patch
* mm-align-struct-page-more-aesthetically.patch
* mm-de-indent-struct-page.patch
* mm-remove-misleading-alignment-claims.patch
* mm-improve-comment-on-page-mapping.patch
* mm-introduce-_slub_counter_t.patch
* mm-store-compound_dtor-compound_order-as-bytes.patch
* mm-store-compound_dtor-compound_order-as-bytes-fix.patch
* mm-document-how-to-use-struct-page.patch
* mm-remove-reference-to-pg_buddy.patch
* shmem-unexport-shmem_add_seals-shmem_get_seals.patch
* shmem-rename-functions-that-are-memfd-related.patch
* hugetlb-expose-hugetlbfs_inode_info-in-header.patch
* hugetlb-implement-memfd-sealing.patch
* shmem-add-sealing-support-to-hugetlb-backed-memfd.patch
* memfd-test-test-hugetlbfs-sealing.patch
* memfd-test-add-memfd-hugetlb-prefix-when-testing-hugetlbfs.patch
* memfd-test-move-common-code-to-a-shared-unit.patch
* memfd-test-run-fuse-test-on-hugetlb-backend-memory.patch
* userfaultfd-convert-to-use-anon_inode_getfd.patch
* mm-pin-address_space-before-dereferencing-it-while-isolating-an-lru-page.patch
* mm-numa-rework-do_pages_move.patch
* mm-migrate-remove-reason-argument-from-new_page_t.patch
* mm-migrate-remove-reason-argument-from-new_page_t-fix.patch
* mm-unclutter-thp-migration.patch
* mm-hugetlb-unify-core-page-allocation-accounting-and-initialization.patch
* mm-hugetlb-integrate-giga-hugetlb-more-naturally-to-the-allocation-path.patch
* mm-hugetlb-do-not-rely-on-overcommit-limit-during-migration.patch
* mm-hugetlb-get-rid-of-surplus-page-accounting-tricks.patch
* mm-hugetlb-further-simplify-hugetlb-allocation-api.patch
* hugetlb-mempolicy-fix-the-mbind-hugetlb-migration.patch
* mm-page_owner-align-with-pageblock_nr_pages.patch
* mm-make-count-list_lru_one-nr_items-lockless.patch
* mm-make-count-list_lru_one-nr_items-lockless-v2.patch
* mm-page_owner-align-with-pageblock_nr-pages.patch
* kasan-add-compiler-support-for-clang.patch
* kasan-makefile-support-llvm-style-asan-parameters.patch
* kasan-support-alloca-poisoning.patch
* kasan-add-tests-for-alloca-poisoning.patch
* kasan-added-functions-for-unpoisoning-stack-variables.patch
* kasan-added-functions-for-unpoisoning-stack-variables-fix.patch
* kasan-detect-invalid-frees-for-large-objects.patch
* kasan-dont-use-__builtin_return_address1.patch
* kasan-detect-invalid-frees-for-large-mempool-objects.patch
* kasan-unify-code-between-kasan_slab_free-and-kasan_poison_kfree.patch
* kasan-detect-invalid-frees.patch
* proc-use-%u-for-pid-printing-and-slightly-less-stack.patch
* proc-dont-use-read_once-write_once-for-proc-fail-nth.patch
* proc-fix-proc-map_files-lookup.patch
* proc-simpler-proc-vmcore-cleanup.patch
* proc-less-memory-for-proc-map_files-readdir.patch
* proc-delete-children_seq_release.patch
* fs-proc-kcorec-use-probe_kernel_read-instead-of-memcpy.patch
* proc-rearrange-struct-proc_dir_entry.patch
* proc-fixup-comment.patch
* proc-spread-__ro_after_init.patch
* proc-spread-likely-unlikely-a-bit.patch
* proc-rearrange-args.patch
* makefile-move-stack-protector-compiler-breakage-test-earlier.patch
* makefile-move-stack-protector-availability-out-of-kconfig.patch
* makefile-introduce-config_cc_stackprotector_auto.patch
* bugh-work-around-gcc-pr82365-in-bug.patch
* uuid-cleanup-uapi-linux-uuidh.patch
* tools-lib-subcmd-do-not-alias-select-params.patch
* revert-async-simplify-lowest_in_progress.patch
* bitmap-new-bitmap_copy_safe-and-bitmap_fromto_arr32.patch
* bitmap-replace-bitmap_fromto_u32array.patch
* lib-stackdepot-use-a-non-instrumented-version-of-memcmp.patch
* lib-test_find_bitc-rename-to-find_bit_benchmarkc.patch
* lib-find_bit_benchmarkc-improvements.patch
* lib-optimize-cpumask_next_and.patch
* lib-optimize-cpumask_next_and-v6.patch
* lib-optimize-cpumask_next_and-v6-fix.patch
* make-runtime_tests-a-menuconfig-to-ease-disabling-it-all.patch
* lib-add-module-unload-support-to-sort-tests.patch
* checkpatch-allow-long-lines-containing-url.patch
* checkpatch-ignore-some-octal-permissions-of-0.patch
* checkpatch-improve-quoted-string-and-line-continuation-test.patch
* checkpatch-add-a-few-device_attr-style-tests.patch
* checkpatch-improve-the-tabstop-test-to-include-declarations.patch
* kallsyms-let-print_ip_sym-print-raw-addresses.patch
* hfsplus-honor-setgid-flag-on-directories.patch
* seq_file-delete-small-value-optimization.patch
* forkc-check-error-and-return-early.patch
* forkc-add-doc-about-usage-of-clone_fs-flags-and-namespaces.patch
* cpumask-make-cpumask_size-return-unsigned-int.patch
* kdump-vmcoreinfo-report-actual-value-of-phys_base.patch
* rapidio-delete-an-error-message-for-a-failed-memory-allocation-in-rio_init_mports.patch
* rapidio-adjust-12-checks-for-null-pointers.patch
* rapidio-adjust-five-function-calls-together-with-a-variable-assignment.patch
* rapidio-improve-a-size-determination-in-five-functions.patch
* rapidio-delete-an-unnecessary-variable-initialisation-in-three-functions.patch
* rapidio-return-an-error-code-only-as-a-constant-in-two-functions.patch
* rapidio-move-12-export_symbol_gpl-calls-to-function-implementations.patch
* rapidio-tsi721_dma-delete-an-error-message-for-a-failed-memory-allocation-in-tsi721_alloc_chan_resources.patch
* rapidio-tsi721_dma-delete-an-unnecessary-variable-initialisation-in-tsi721_alloc_chan_resources.patch
* rapidio-tsi721_dma-adjust-six-checks-for-null-pointers.patch
* uapi-fix-linux-sysctlh-userspace-compilation-errors.patch
* pids-introduce-find_get_task_by_vpid-helper.patch
* lib-ubsanc-s-missaligned-misaligned.patch
* ipc-fix-ipc-data-structures-inconsistency.patch
* ipc-mqueue-wq_add-priority-changed-to-dynamic-priority.patch
  linux-next.patch
  linux-next-rejects.patch
  linux-next-git-rejects.patch
* tools-objtool-makefile-dont-assume-sync-checksh-is-executable.patch
* vfs-remove-might_sleep-from-clear_inode.patch
* mm-remove-duplicate-includes.patch
* mm-remove-unneeded-kallsyms-include.patch
* hrtimer-remove-unneeded-kallsyms-include.patch
* genirq-remove-unneeded-kallsyms-include.patch
* mm-memblock-memblock_is_map-region_memory-can-be-boolean.patch
* lib-lockref-__lockref_is_dead-can-be-boolean.patch
* kernel-cpuset-current_cpuset_is_being_rebound-can-be-boolean.patch
* kernel-resource-iomem_is_exclusive-can-be-boolean.patch
* kernel-module-module_is_live-can-be-boolean.patch
* kernel-mutex-mutex_is_locked-can-be-boolean.patch
* crash_dump-is_kdump_kernel-can-be-boolean.patch
* fix-const-confusion-in-certs-blacklist.patch
* fix-read-buffer-overflow-in-delta-ipc.patch
* fix-const-confusion-in-intel-mid-x86-platform-drivers.patch
* kasan-rework-kconfig-settings.patch
* sparc64-ng4-memset-32-bits-overflow.patch
* lib-crc-ccitt-add-ccitt-false-crc16-variant.patch
  make-sure-nobodys-leaking-resources.patch
  releasing-resources-with-children.patch
  kernel-forkc-export-kernel_thread-to-modules.patch
  mutex-subsystem-synchro-test-module.patch
  slab-leaks3-default-y.patch
  workaround-for-a-pci-restoring-bug.patch

^ permalink raw reply	[flat|nested] 82+ messages in thread

* mmotm 2018-01-04-16-19 uploaded
@ 2018-01-05  0:20 ` akpm
  0 siblings, 0 replies; 82+ messages in thread
From: akpm @ 2018-01-05  0:20 UTC (permalink / raw)
  To: mm-commits, linux-kernel, linux-mm, linux-fsdevel, linux-next,
	sfr, mhocko, broonie

The mm-of-the-moment snapshot 2018-01-04-16-19 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (4.x
or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE-yyyy-mm-dd-hh-mm-ss.  Both contain the string yyyy-mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/

To develop on top of mmotm git:

  $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  <make changes, commit>
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master <topic base> topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

	http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 4.15-rc6:
(patches marked "*" will be included in linux-next)

  origin.patch
  i-need-old-gcc.patch
* mm-check-pfn_valid-first-in-zero_resv_unavail.patch
* acct-fix-the-acct-needcheck-check-in-check_free_space.patch
* mm-mprotect-add-a-cond_resched-inside-change_pmd_range.patch
* kernel-exitc-export-abort-to-modules.patch
* provide-useful-debugging-information-for-vm_bug.patch
* zsmalloc-add-fsh-include.patch
* mm-sparsec-wrong-allocation-for-mem_section.patch
* userfaultfd-clear-the-vma-vm_userfaultfd_ctx-if-uffd_event_fork-fails.patch
* mailmap-update-mark-yaos-email-address.patch
* scripts-decodecode-fix-decoding-for-aarch64-arm64-instructions.patch
* mm-skip-hwpoisoned-pages-when-onlining-pages.patch
* mm-release-locked-page-in-do_swap_page.patch
* arm-arch-arm-include-asm-pageh-needs-personalityh.patch
* prctl-add-pr_et_pdeathsig_proc.patch
* scripts-decodecode-make-it-take-multiline-code-line.patch
* scripts-tags-change-find_other_sources-for-include-folders.patch
* ocfs2-dlm-clean-dead-code-up.patch
* ocfs2-cluster-neaten-a-member-of-o2net_msg_handler.patch
* ocfs2-give-an-obvious-tip-for-dismatch-cluster-names.patch
* ocfs2-cluster-close-a-race-that-fence-cant-be-triggered.patch
* ocfs2-using-the-ocfs2_xattr_root_size-macro-in-ocfs2_reflink_xattr_header.patch
* ocfs2-clean-dead-code-in-suballocc.patch
* ocfs2-return-erofs-to-mountocfs2-if-inode-block-is-invalid.patch
* ocfs2-get-rid-of-ocfs2_is_o2cb_active-function.patch
* ocfs2-move-some-definitions-to-header-file.patch
* ocfs2-fix-some-small-problems.patch
* ocfs2-add-kobject-for-online-file-check.patch
* ocfs2-add-duplicative-ino-number-check.patch
* ocfs2-add-ocfs2_try_rw_lock-and-ocfs2_try_inode_lock.patch
* ocfs2-add-ocfs2_overwrite_io-function.patch
* ocfs2-add-ocfs2_overwrite_io-function-v3.patch
* ocfs2-nowait-aio-support.patch
* ocfs2-add-trimfs-dlm-lock-resource.patch
* ocfs2-add-trimfs-lock-to-avoid-duplicated-trims-in-cluster.patch
* ocfs2-try-a-blocking-lock-before-return-aop_truncated_page.patch
* block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch
* dentry-fix-kmemcheck-splat-at-take_dentry_name_snapshot.patch
  mm.patch
* mm-terminate-shrink_slab-loop-if-signal-is-pending.patch
* mm-terminate-shrink_slab-loop-if-signal-is-pending-fix.patch
* mm-slab-make-calculate_alignment-function-static.patch
* mm-slab-remove-redundant-assignments-for-slab_state.patch
* include-linux-sched-mmh-uninline-mmdrop_async-etc.patch
* mm-kmemleak-remove-unused-hardirqh.patch
* zswap-same-filled-pages-handling.patch
* zswap-same-filled-pages-handling-v2.patch
* mm-relax-deferred-struct-page-requirements.patch
* mm-mempolicy-remove-redundant-check-in-get_nodes.patch
* mm-mempolicy-fix-the-check-of-nodemask-from-user.patch
* mm-mempolicy-add-nodes_empty-check-in-sysc_migrate_pages.patch
* mm-drop-hotplug-lock-from-lru_add_drain_all.patch
* mm-show-total-hugetlb-memory-consumption-in-proc-meminfo.patch
* mm-use-sc-priority-for-slab-shrink-targets.patch
* mm-mlock-vmscan-no-more-skipping-pagevecs.patch
* mmvmscan-mark-register_shrinker-as-__must_check.patch
* mm-split-deferred_init_range-into-initializing-and-freeing-parts.patch
* mm-split-deferred_init_range-into-initializing-and-freeing-parts-fix.patch
* mm-filemap-remove-include-of-hardirqh.patch
* mm-memcontrol-eliminate-raw-access-to-stat-and-event-counters.patch
* mm-memcontrol-implement-lruvec-stat-functions-on-top-of-each-other.patch
* mm-memcontrol-fix-excessive-complexity-in-memorystat-reporting.patch
* mm-memcontrol-fix-excessive-complexity-in-memorystat-reporting-fix.patch
* mm-page_owner-use-ptr_err_or_zero.patch
* mm-page_alloc-fix-comment-is-__get_free_pages.patch
* mm-do-not-stall-register_shrinker.patch
* mm-do-not-stall-register_shrinker-fix.patch
* selftest-vm-move-128tb-mmap-boundary-test-to-generic-directory.patch
* selftest-vm-move-128tb-mmap-boundary-test-to-generic-directory-fix.patch
* mm-use-vma_pages-helper.patch
* mm-remove-unused-pgdat_reclaimable_pages.patch
* list_lru-prefetch-neighboring-list-entries-before-acquiring-lock.patch
* list_lru-prefetch-neighboring-list-entries-before-acquiring-lock-fix.patch
* mm-oom-refactor-the-oom_kill_process-function.patch
* mm-implement-mem_cgroup_scan_tasks-for-the-root-memory-cgroup.patch
* mm-oom-cgroup-aware-oom-killer.patch
* mm-oom-cgroup-aware-oom-killer-fix.patch
* mm-oom-introduce-memoryoom_group.patch
* mm-oom-introduce-memoryoom_group-fix.patch
* mm-oom-add-cgroup-v2-mount-option-for-cgroup-aware-oom-killer.patch
* mm-oom-docs-describe-the-cgroup-aware-oom-killer.patch
* mm-oom-docs-describe-the-cgroup-aware-oom-killer-fix.patch
* cgroup-list-groupoom-in-cgroup-features.patch
* mm-hugetlb-drop-hugepages_treat_as_movable-sysctl.patch
* mm-memory_hotplug-remove-unnecesary-check-from-register_page_bootmem_info_section.patch
* mm-update-comment-describing-tlb_gather_mmu.patch
* proc-do-not-show-vmexe-bigger-than-total-executable-virtual-memory.patch
* mm-add-strictlimit-knob-v2.patch
* mm-memory_hotplug-remove-second-__nr_to_section-in-register_page_bootmem_info_section.patch
* mm-huge_memory-fix-comment-in-__split_huge_pmd_locked.patch
* mm-userfaultfd-thp-avoid-waiting-when-pmd-under-thp-migration.patch
* mm-page_alloc-dont-reserve-zone_highmem-for-zone_movable-request.patch
* mm-cma-manage-the-memory-of-the-cma-area-by-using-the-zone_movable.patch
* mm-cma-remove-alloc_cma.patch
* arm-cma-avoid-double-mapping-to-the-cma-area-if-config_highmem-=-y.patch
* mm-add-unmap_mapping_pages.patch
* get-7%-more-pages-in-a-pagevec.patch
* asm-generic-provide-generic_pmdp_establish.patch
* arc-use-generic_pmdp_establish-as-pmdp_establish.patch
* arm-mm-provide-pmdp_establish-helper.patch
* arm64-provide-pmdp_establish-helper.patch
* mips-use-generic_pmdp_establish-as-pmdp_establish.patch
* powerpc-mm-update-pmdp_invalidate-to-return-old-pmd-value.patch
* s390-mm-modify-pmdp_invalidate-to-return-old-value.patch
* sparc64-update-pmdp_invalidate-to-return-old-pmd-value.patch
* sparc64-update-pmdp_invalidate-to-return-old-pmd-value-fix.patch
* x86-mm-provide-pmdp_establish-helper.patch
* x86-mm-provide-pmdp_establish-helper-fix.patch
* mm-do-not-lose-dirty-and-access-bits-in-pmdp_invalidate.patch
* mm-use-updated-pmdp_invalidate-interface-to-track-dirty-accessed-bits.patch
* mm-thp-remove-pmd_huge_split_prepare.patch
* mm-introduce-map_fixed_safe.patch
* mm-introduce-map_fixed_safe-fix.patch
* fs-elf-drop-map_fixed-usage-from-elf_map.patch
* fs-elf-drop-map_fixed-usage-from-elf_map-fix.patch
* fs-elf-drop-map_fixed-usage-from-elf_map-checkpatch-fixes.patch
* mm-thp-use-down_read_trylock-in-khugepaged-to-avoid-long-block.patch
* mm-thp-use-down_read_trylock-in-khugepaged-to-avoid-long-block-fix.patch
* mm-thp-use-down_read_trylock-in-khugepaged-to-avoid-long-block-fix-2.patch
* mm-thp-use-down_read_trylock-in-khugepaged-to-avoid-long-block-fix-checkpatch-fixes.patch
* mm-mmu_notifier-annotate-mmu-notifiers-with-blockable-invalidate-callbacks.patch
* mm-mmu_notifier-annotate-mmu-notifiers-with-blockable-invalidate-callbacks-fix.patch
* mm-oom-avoid-reaping-only-for-mms-with-blockable-invalidate-callbacks.patch
* mm-zsmalloc-simplify-shrinker-init-destroy.patch
* mm-zsmalloc-simplify-shrinker-init-destroy-fix.patch
* mm-vmalloc-replace-opencoded-4-level-page-walkers.patch
* mm-align-struct-page-more-aesthetically.patch
* mm-de-indent-struct-page.patch
* mm-remove-misleading-alignment-claims.patch
* mm-improve-comment-on-page-mapping.patch
* mm-introduce-_slub_counter_t.patch
* mm-store-compound_dtor-compound_order-as-bytes.patch
* mm-store-compound_dtor-compound_order-as-bytes-fix.patch
* mm-document-how-to-use-struct-page.patch
* mm-remove-reference-to-pg_buddy.patch
* shmem-unexport-shmem_add_seals-shmem_get_seals.patch
* shmem-rename-functions-that-are-memfd-related.patch
* hugetlb-expose-hugetlbfs_inode_info-in-header.patch
* hugetlb-implement-memfd-sealing.patch
* shmem-add-sealing-support-to-hugetlb-backed-memfd.patch
* memfd-test-test-hugetlbfs-sealing.patch
* memfd-test-add-memfd-hugetlb-prefix-when-testing-hugetlbfs.patch
* memfd-test-move-common-code-to-a-shared-unit.patch
* memfd-test-run-fuse-test-on-hugetlb-backend-memory.patch
* userfaultfd-convert-to-use-anon_inode_getfd.patch
* mm-pin-address_space-before-dereferencing-it-while-isolating-an-lru-page.patch
* mm-numa-rework-do_pages_move.patch
* mm-migrate-remove-reason-argument-from-new_page_t.patch
* mm-migrate-remove-reason-argument-from-new_page_t-fix.patch
* mm-unclutter-thp-migration.patch
* mm-hugetlb-unify-core-page-allocation-accounting-and-initialization.patch
* mm-hugetlb-integrate-giga-hugetlb-more-naturally-to-the-allocation-path.patch
* mm-hugetlb-do-not-rely-on-overcommit-limit-during-migration.patch
* mm-hugetlb-get-rid-of-surplus-page-accounting-tricks.patch
* mm-hugetlb-further-simplify-hugetlb-allocation-api.patch
* hugetlb-mempolicy-fix-the-mbind-hugetlb-migration.patch
* mm-page_owner-align-with-pageblock_nr_pages.patch
* mm-make-count-list_lru_one-nr_items-lockless.patch
* mm-make-count-list_lru_one-nr_items-lockless-v2.patch
* mm-page_owner-align-with-pageblock_nr-pages.patch
* kasan-add-compiler-support-for-clang.patch
* kasan-makefile-support-llvm-style-asan-parameters.patch
* kasan-support-alloca-poisoning.patch
* kasan-add-tests-for-alloca-poisoning.patch
* kasan-added-functions-for-unpoisoning-stack-variables.patch
* kasan-added-functions-for-unpoisoning-stack-variables-fix.patch
* kasan-detect-invalid-frees-for-large-objects.patch
* kasan-dont-use-__builtin_return_address1.patch
* kasan-detect-invalid-frees-for-large-mempool-objects.patch
* kasan-unify-code-between-kasan_slab_free-and-kasan_poison_kfree.patch
* kasan-detect-invalid-frees.patch
* proc-use-%u-for-pid-printing-and-slightly-less-stack.patch
* proc-dont-use-read_once-write_once-for-proc-fail-nth.patch
* proc-fix-proc-map_files-lookup.patch
* proc-simpler-proc-vmcore-cleanup.patch
* proc-less-memory-for-proc-map_files-readdir.patch
* proc-delete-children_seq_release.patch
* fs-proc-kcorec-use-probe_kernel_read-instead-of-memcpy.patch
* proc-rearrange-struct-proc_dir_entry.patch
* proc-fixup-comment.patch
* proc-spread-__ro_after_init.patch
* proc-spread-likely-unlikely-a-bit.patch
* proc-rearrange-args.patch
* makefile-move-stack-protector-compiler-breakage-test-earlier.patch
* makefile-move-stack-protector-availability-out-of-kconfig.patch
* makefile-introduce-config_cc_stackprotector_auto.patch
* bugh-work-around-gcc-pr82365-in-bug.patch
* uuid-cleanup-uapi-linux-uuidh.patch
* tools-lib-subcmd-do-not-alias-select-params.patch
* revert-async-simplify-lowest_in_progress.patch
* bitmap-new-bitmap_copy_safe-and-bitmap_fromto_arr32.patch
* bitmap-replace-bitmap_fromto_u32array.patch
* lib-stackdepot-use-a-non-instrumented-version-of-memcmp.patch
* lib-test_find_bitc-rename-to-find_bit_benchmarkc.patch
* lib-find_bit_benchmarkc-improvements.patch
* lib-optimize-cpumask_next_and.patch
* lib-optimize-cpumask_next_and-v6.patch
* lib-optimize-cpumask_next_and-v6-fix.patch
* make-runtime_tests-a-menuconfig-to-ease-disabling-it-all.patch
* lib-add-module-unload-support-to-sort-tests.patch
* checkpatch-allow-long-lines-containing-url.patch
* checkpatch-ignore-some-octal-permissions-of-0.patch
* checkpatch-improve-quoted-string-and-line-continuation-test.patch
* checkpatch-add-a-few-device_attr-style-tests.patch
* checkpatch-improve-the-tabstop-test-to-include-declarations.patch
* kallsyms-let-print_ip_sym-print-raw-addresses.patch
* hfsplus-honor-setgid-flag-on-directories.patch
* seq_file-delete-small-value-optimization.patch
* forkc-check-error-and-return-early.patch
* forkc-add-doc-about-usage-of-clone_fs-flags-and-namespaces.patch
* cpumask-make-cpumask_size-return-unsigned-int.patch
* kdump-vmcoreinfo-report-actual-value-of-phys_base.patch
* rapidio-delete-an-error-message-for-a-failed-memory-allocation-in-rio_init_mports.patch
* rapidio-adjust-12-checks-for-null-pointers.patch
* rapidio-adjust-five-function-calls-together-with-a-variable-assignment.patch
* rapidio-improve-a-size-determination-in-five-functions.patch
* rapidio-delete-an-unnecessary-variable-initialisation-in-three-functions.patch
* rapidio-return-an-error-code-only-as-a-constant-in-two-functions.patch
* rapidio-move-12-export_symbol_gpl-calls-to-function-implementations.patch
* rapidio-tsi721_dma-delete-an-error-message-for-a-failed-memory-allocation-in-tsi721_alloc_chan_resources.patch
* rapidio-tsi721_dma-delete-an-unnecessary-variable-initialisation-in-tsi721_alloc_chan_resources.patch
* rapidio-tsi721_dma-adjust-six-checks-for-null-pointers.patch
* uapi-fix-linux-sysctlh-userspace-compilation-errors.patch
* pids-introduce-find_get_task_by_vpid-helper.patch
* lib-ubsanc-s-missaligned-misaligned.patch
* ipc-fix-ipc-data-structures-inconsistency.patch
* ipc-mqueue-wq_add-priority-changed-to-dynamic-priority.patch
  linux-next.patch
  linux-next-rejects.patch
  linux-next-git-rejects.patch
* tools-objtool-makefile-dont-assume-sync-checksh-is-executable.patch
* vfs-remove-might_sleep-from-clear_inode.patch
* mm-remove-duplicate-includes.patch
* mm-remove-unneeded-kallsyms-include.patch
* hrtimer-remove-unneeded-kallsyms-include.patch
* genirq-remove-unneeded-kallsyms-include.patch
* mm-memblock-memblock_is_map-region_memory-can-be-boolean.patch
* lib-lockref-__lockref_is_dead-can-be-boolean.patch
* kernel-cpuset-current_cpuset_is_being_rebound-can-be-boolean.patch
* kernel-resource-iomem_is_exclusive-can-be-boolean.patch
* kernel-module-module_is_live-can-be-boolean.patch
* kernel-mutex-mutex_is_locked-can-be-boolean.patch
* crash_dump-is_kdump_kernel-can-be-boolean.patch
* fix-const-confusion-in-certs-blacklist.patch
* fix-read-buffer-overflow-in-delta-ipc.patch
* fix-const-confusion-in-intel-mid-x86-platform-drivers.patch
* kasan-rework-kconfig-settings.patch
* sparc64-ng4-memset-32-bits-overflow.patch
* lib-crc-ccitt-add-ccitt-false-crc16-variant.patch
  make-sure-nobodys-leaking-resources.patch
  releasing-resources-with-children.patch
  kernel-forkc-export-kernel_thread-to-modules.patch
  mutex-subsystem-synchro-test-module.patch
  slab-leaks3-default-y.patch
  workaround-for-a-pci-restoring-bug.patch

--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: mmotm 2018-01-04-16-19 uploaded
  2018-01-05  0:20 ` akpm
@ 2018-01-05  6:43   ` Anshuman Khandual
  -1 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-05  6:43 UTC (permalink / raw)
  To: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, mhocko, broonie

On 01/05/2018 05:50 AM, akpm@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2018-01-04-16-19 has been uploaded to
> 
>    http://www.ozlabs.org/~akpm/mmotm/
> 
> mmotm-readme.txt says
> 
> README for mm-of-the-moment:
> 
> http://www.ozlabs.org/~akpm/mmotm/
> 
> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> more than once a week.
> 
> You will need quilt to apply these patches to the latest Linus release (4.x
> or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
> http://ozlabs.org/~akpm/mmotm/series
> 
> The file broken-out.tar.gz contains two datestamp files: .DATE and
> .DATE-yyyy-mm-dd-hh-mm-ss.  Both contain the string yyyy-mm-dd-hh-mm-ss,
> followed by the base kernel version against which this patch series is to
> be applied.
> 
> This tree is partially included in linux-next.  To see which patches are
> included in linux-next, consult the `series' file.  Only the patches
> within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
> linux-next.
> 
> A git tree which contains the memory management portion of this tree is
> maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git

Seems like this latest snapshot mmotm-2018-01-04-16-19 has not been
updated in this git tree. I could not fetch not it shows up in the
http link below.

https://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git

The last one mmotm-2017-12-22-17-55 seems to have some regression on
powerpc with respect to ELF loading of binaries (see below). Seems to
be related to recent MAP_FIXED_SAFE (or MAP_FIXED_NOREPLACE as seen
now in the code). IIUC (have not been following the series last month)
MAP_FIXED_NOREPLACE will fail an allocation request if the hint address
cannot be reserve instead of changing existing mappings. Is it possible
that ELF loading needs to be fixed at a higher level to deal with these
new possible mmap() failures because of MAP_FIXED_NOREPLACE ?

[   22.448068] 9060 (hostname): Uhuuh, elf segment at 0000000010020000 requested but the memory is mapped already
[   22.450135] 9063 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   22.456484] 9066 (hostname): Uhuuh, elf segment at 0000000010020000 requested but the memory is mapped already
[   22.458171] 9069 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   22.505341] 9078 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   22.506961] 9081 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   22.508736] 9084 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   22.510589] 9087 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   22.512442] 9090 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   22.514685] 9093 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   22.565793] 9103 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   22.567874] 9106 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[  123.469490] 9173 (fprintd): Uhuuh, elf segment at 0000000010020000 requested but the memory is mapped already
[  137.468372] 9182 (hostname): Uhuuh, elf segment at 0000000010020000 requested but the memory is mapped already
[  137.644647] 9205 (pkg-config): Uhuuh, elf segment at 0000000010020000 requested but the memory is mapped already
[  137.811893] 9219 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[  164.739135] 9232 (less): Uhuuh, elf segment at 0000000010040000 requested but the memory is mapped already

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: mmotm 2018-01-04-16-19 uploaded
@ 2018-01-05  6:43   ` Anshuman Khandual
  0 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-05  6:43 UTC (permalink / raw)
  To: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, mhocko, broonie

On 01/05/2018 05:50 AM, akpm@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2018-01-04-16-19 has been uploaded to
> 
>    http://www.ozlabs.org/~akpm/mmotm/
> 
> mmotm-readme.txt says
> 
> README for mm-of-the-moment:
> 
> http://www.ozlabs.org/~akpm/mmotm/
> 
> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> more than once a week.
> 
> You will need quilt to apply these patches to the latest Linus release (4.x
> or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
> http://ozlabs.org/~akpm/mmotm/series
> 
> The file broken-out.tar.gz contains two datestamp files: .DATE and
> .DATE-yyyy-mm-dd-hh-mm-ss.  Both contain the string yyyy-mm-dd-hh-mm-ss,
> followed by the base kernel version against which this patch series is to
> be applied.
> 
> This tree is partially included in linux-next.  To see which patches are
> included in linux-next, consult the `series' file.  Only the patches
> within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
> linux-next.
> 
> A git tree which contains the memory management portion of this tree is
> maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git

Seems like this latest snapshot mmotm-2018-01-04-16-19 has not been
updated in this git tree. I could not fetch not it shows up in the
http link below.

https://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git

The last one mmotm-2017-12-22-17-55 seems to have some regression on
powerpc with respect to ELF loading of binaries (see below). Seems to
be related to recent MAP_FIXED_SAFE (or MAP_FIXED_NOREPLACE as seen
now in the code). IIUC (have not been following the series last month)
MAP_FIXED_NOREPLACE will fail an allocation request if the hint address
cannot be reserve instead of changing existing mappings. Is it possible
that ELF loading needs to be fixed at a higher level to deal with these
new possible mmap() failures because of MAP_FIXED_NOREPLACE ?

[   22.448068] 9060 (hostname): Uhuuh, elf segment at 0000000010020000 requested but the memory is mapped already
[   22.450135] 9063 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   22.456484] 9066 (hostname): Uhuuh, elf segment at 0000000010020000 requested but the memory is mapped already
[   22.458171] 9069 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   22.505341] 9078 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   22.506961] 9081 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   22.508736] 9084 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   22.510589] 9087 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   22.512442] 9090 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   22.514685] 9093 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   22.565793] 9103 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   22.567874] 9106 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[  123.469490] 9173 (fprintd): Uhuuh, elf segment at 0000000010020000 requested but the memory is mapped already
[  137.468372] 9182 (hostname): Uhuuh, elf segment at 0000000010020000 requested but the memory is mapped already
[  137.644647] 9205 (pkg-config): Uhuuh, elf segment at 0000000010020000 requested but the memory is mapped already
[  137.811893] 9219 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[  164.739135] 9232 (less): Uhuuh, elf segment at 0000000010040000 requested but the memory is mapped already

--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: mmotm 2018-01-04-16-19 uploaded
  2018-01-05  6:43   ` Anshuman Khandual
@ 2018-01-05  8:46     ` Michal Hocko
  -1 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-05  8:46 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, broonie

On Fri 05-01-18 12:13:17, Anshuman Khandual wrote:
> On 01/05/2018 05:50 AM, akpm@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2018-01-04-16-19 has been uploaded to
> > 
> >    http://www.ozlabs.org/~akpm/mmotm/
> > 
> > mmotm-readme.txt says
> > 
> > README for mm-of-the-moment:
> > 
> > http://www.ozlabs.org/~akpm/mmotm/
> > 
> > This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> > more than once a week.
> > 
> > You will need quilt to apply these patches to the latest Linus release (4.x
> > or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
> > http://ozlabs.org/~akpm/mmotm/series
> > 
> > The file broken-out.tar.gz contains two datestamp files: .DATE and
> > .DATE-yyyy-mm-dd-hh-mm-ss.  Both contain the string yyyy-mm-dd-hh-mm-ss,
> > followed by the base kernel version against which this patch series is to
> > be applied.
> > 
> > This tree is partially included in linux-next.  To see which patches are
> > included in linux-next, consult the `series' file.  Only the patches
> > within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
> > linux-next.
> > 
> > A git tree which contains the memory management portion of this tree is
> > maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> 
> Seems like this latest snapshot mmotm-2018-01-04-16-19 has not been
> updated in this git tree. I could not fetch not it shows up in the
> http link below.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git

I will update the tree today (WIP). This is not a fully automated
process and Andrew pushed his tree during my night ;) So be patient
please. My tree is non-rebasing which means I cannot just throw the old
tree away and regenerate it from scratch.

> The last one mmotm-2017-12-22-17-55 seems to have some regression on
> powerpc with respect to ELF loading of binaries (see below). Seems to
> be related to recent MAP_FIXED_SAFE (or MAP_FIXED_NOREPLACE as seen
> now in the code). IIUC (have not been following the series last month)
> MAP_FIXED_NOREPLACE will fail an allocation request if the hint address
> cannot be reserve instead of changing existing mappings.

Correct

> Is it possible
> that ELF loading needs to be fixed at a higher level to deal with these
> new possible mmap() failures because of MAP_FIXED_NOREPLACE ?

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.

Thanks
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: mmotm 2018-01-04-16-19 uploaded
@ 2018-01-05  8:46     ` Michal Hocko
  0 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-05  8:46 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, broonie

On Fri 05-01-18 12:13:17, Anshuman Khandual wrote:
> On 01/05/2018 05:50 AM, akpm@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2018-01-04-16-19 has been uploaded to
> > 
> >    http://www.ozlabs.org/~akpm/mmotm/
> > 
> > mmotm-readme.txt says
> > 
> > README for mm-of-the-moment:
> > 
> > http://www.ozlabs.org/~akpm/mmotm/
> > 
> > This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> > more than once a week.
> > 
> > You will need quilt to apply these patches to the latest Linus release (4.x
> > or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
> > http://ozlabs.org/~akpm/mmotm/series
> > 
> > The file broken-out.tar.gz contains two datestamp files: .DATE and
> > .DATE-yyyy-mm-dd-hh-mm-ss.  Both contain the string yyyy-mm-dd-hh-mm-ss,
> > followed by the base kernel version against which this patch series is to
> > be applied.
> > 
> > This tree is partially included in linux-next.  To see which patches are
> > included in linux-next, consult the `series' file.  Only the patches
> > within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
> > linux-next.
> > 
> > A git tree which contains the memory management portion of this tree is
> > maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> 
> Seems like this latest snapshot mmotm-2018-01-04-16-19 has not been
> updated in this git tree. I could not fetch not it shows up in the
> http link below.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git

I will update the tree today (WIP). This is not a fully automated
process and Andrew pushed his tree during my night ;) So be patient
please. My tree is non-rebasing which means I cannot just throw the old
tree away and regenerate it from scratch.

> The last one mmotm-2017-12-22-17-55 seems to have some regression on
> powerpc with respect to ELF loading of binaries (see below). Seems to
> be related to recent MAP_FIXED_SAFE (or MAP_FIXED_NOREPLACE as seen
> now in the code). IIUC (have not been following the series last month)
> MAP_FIXED_NOREPLACE will fail an allocation request if the hint address
> cannot be reserve instead of changing existing mappings.

Correct

> Is it possible
> that ELF loading needs to be fixed at a higher level to deal with these
> new possible mmap() failures because of MAP_FIXED_NOREPLACE ?

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.

Thanks
-- 
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: mmotm 2018-01-04-16-19 uploaded
  2018-01-05  6:43   ` Anshuman Khandual
@ 2018-01-05 12:14     ` Michal Hocko
  -1 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-05 12:14 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, broonie

On Fri 05-01-18 12:13:17, Anshuman Khandual wrote:
> On 01/05/2018 05:50 AM, akpm@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2018-01-04-16-19 has been uploaded to
> > 
> >    http://www.ozlabs.org/~akpm/mmotm/
> > 
> > mmotm-readme.txt says
> > 
> > README for mm-of-the-moment:
> > 
> > http://www.ozlabs.org/~akpm/mmotm/
> > 
> > This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> > more than once a week.
> > 
> > You will need quilt to apply these patches to the latest Linus release (4.x
> > or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
> > http://ozlabs.org/~akpm/mmotm/series
> > 
> > The file broken-out.tar.gz contains two datestamp files: .DATE and
> > .DATE-yyyy-mm-dd-hh-mm-ss.  Both contain the string yyyy-mm-dd-hh-mm-ss,
> > followed by the base kernel version against which this patch series is to
> > be applied.
> > 
> > This tree is partially included in linux-next.  To see which patches are
> > included in linux-next, consult the `series' file.  Only the patches
> > within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
> > linux-next.
> > 
> > A git tree which contains the memory management portion of this tree is
> > maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> 
> Seems like this latest snapshot mmotm-2018-01-04-16-19 has not been
> updated in this git tree. I could not fetch not it shows up in the
> http link below.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git

Just for the record. mmotm-2018-01-04-16-19 has been just pushed out to
the mirror. It took longer than usually because I am bussy as hell...
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: mmotm 2018-01-04-16-19 uploaded
@ 2018-01-05 12:14     ` Michal Hocko
  0 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-05 12:14 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, broonie

On Fri 05-01-18 12:13:17, Anshuman Khandual wrote:
> On 01/05/2018 05:50 AM, akpm@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2018-01-04-16-19 has been uploaded to
> > 
> >    http://www.ozlabs.org/~akpm/mmotm/
> > 
> > mmotm-readme.txt says
> > 
> > README for mm-of-the-moment:
> > 
> > http://www.ozlabs.org/~akpm/mmotm/
> > 
> > This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> > more than once a week.
> > 
> > You will need quilt to apply these patches to the latest Linus release (4.x
> > or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
> > http://ozlabs.org/~akpm/mmotm/series
> > 
> > The file broken-out.tar.gz contains two datestamp files: .DATE and
> > .DATE-yyyy-mm-dd-hh-mm-ss.  Both contain the string yyyy-mm-dd-hh-mm-ss,
> > followed by the base kernel version against which this patch series is to
> > be applied.
> > 
> > This tree is partially included in linux-next.  To see which patches are
> > included in linux-next, consult the `series' file.  Only the patches
> > within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
> > linux-next.
> > 
> > A git tree which contains the memory management portion of this tree is
> > maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> 
> Seems like this latest snapshot mmotm-2018-01-04-16-19 has not been
> updated in this git tree. I could not fetch not it shows up in the
> http link below.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git

Just for the record. mmotm-2018-01-04-16-19 has been just pushed out to
the mirror. It took longer than usually because I am bussy as hell...
-- 
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: mmotm 2018-01-04-16-19 uploaded
  2018-01-05  8:46     ` Michal Hocko
@ 2018-01-07  6:49       ` Anshuman Khandual
  -1 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-07  6:49 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, broonie

On 01/05/2018 02:16 PM, Michal Hocko wrote:
> On Fri 05-01-18 12:13:17, Anshuman Khandual wrote:
>> On 01/05/2018 05:50 AM, akpm@linux-foundation.org wrote:
>>> The mm-of-the-moment snapshot 2018-01-04-16-19 has been uploaded to

[...]

>>>
>>> This tree is partially included in linux-next.  To see which patches are
>>> included in linux-next, consult the `series' file.  Only the patches
>>> within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
>>> linux-next.
>>>
>>> A git tree which contains the memory management portion of this tree is
>>> maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
>> Seems like this latest snapshot mmotm-2018-01-04-16-19 has not been
>> updated in this git tree. I could not fetch not it shows up in the
>> http link below.
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> I will update the tree today (WIP). This is not a fully automated
> process and Andrew pushed his tree during my night ;) So be patient
> please. My tree is non-rebasing which means I cannot just throw the old
> tree away and regenerate it from scratch.
> 
>> The last one mmotm-2017-12-22-17-55 seems to have some regression on
>> powerpc with respect to ELF loading of binaries (see below). Seems to
>> be related to recent MAP_FIXED_SAFE (or MAP_FIXED_NOREPLACE as seen
>> now in the code). IIUC (have not been following the series last month)
>> MAP_FIXED_NOREPLACE will fail an allocation request if the hint address
>> cannot be reserve instead of changing existing mappings.
> Correct
> 
>> Is it possible
>> that ELF loading needs to be fixed at a higher level to deal with these
>> new possible mmap() failures because of MAP_FIXED_NOREPLACE ?
> 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.

[   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
[   23.426089] 9151 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   23.426232] requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.429048] 9154 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   23.429196] requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.482766] 9164 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   23.482904] requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.485849] 9167 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   23.485945] requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   76.041836] 9262 (hostname): Uhuuh, elf segment at 0000000010020000 requested but the memory is mapped already
[   76.041965] requested [10020000, 10030000] mapped [10020000, 10030000] 100073 anon
[   76.207197] 9285 (pkg-config): Uhuuh, elf segment at 0000000010020000 requested but the memory is mapped already
[   76.207326] requested [10020000, 10030000] mapped [10020000, 10030000] 100073 anon
[   76.371073] 9299 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   76.371165] requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon


I have fixed/changed the debug patch a bit


diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index d8c5657..a43eccaa 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -372,11 +372,35 @@ 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))
+       if ((type & MAP_FIXED_NOREPLACE) && BAD_ADDR(map_addr)) {
+               struct vm_area_struct *vma;
+               unsigned long end;
+
+               if (total_size)
+                       end = addr + total_size;
+               else
+                       end = addr + size;
+
                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);

+               vma = find_vma(current->mm, addr);
+               if (vma && vma->vm_start <= addr) {
+                       pr_info("requested [%lx, %lx] mapped [%lx, %lx] %lx ", addr, end,
+                                       vma->vm_start, vma->vm_end, vma->vm_flags);
+                       if (!vma->vm_file) {
+                               pr_cont("anon\n");
+                       } else {
+                               char path[512];
+                               char *p = file_path(vma->vm_file, path, sizeof(path));
+                               if (IS_ERR(p))
+                                       p = "?";
+                               pr_cont("\"%s\"\n", kbasename(p));
+                       }
+                       dump_stack();
+               }
+       }
        return(map_addr);
 }

^ permalink raw reply related	[flat|nested] 82+ messages in thread

* Re: mmotm 2018-01-04-16-19 uploaded
@ 2018-01-07  6:49       ` Anshuman Khandual
  0 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-07  6:49 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, broonie

On 01/05/2018 02:16 PM, Michal Hocko wrote:
> On Fri 05-01-18 12:13:17, Anshuman Khandual wrote:
>> On 01/05/2018 05:50 AM, akpm@linux-foundation.org wrote:
>>> The mm-of-the-moment snapshot 2018-01-04-16-19 has been uploaded to

[...]

>>>
>>> This tree is partially included in linux-next.  To see which patches are
>>> included in linux-next, consult the `series' file.  Only the patches
>>> within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
>>> linux-next.
>>>
>>> A git tree which contains the memory management portion of this tree is
>>> maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
>> Seems like this latest snapshot mmotm-2018-01-04-16-19 has not been
>> updated in this git tree. I could not fetch not it shows up in the
>> http link below.
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> I will update the tree today (WIP). This is not a fully automated
> process and Andrew pushed his tree during my night ;) So be patient
> please. My tree is non-rebasing which means I cannot just throw the old
> tree away and regenerate it from scratch.
> 
>> The last one mmotm-2017-12-22-17-55 seems to have some regression on
>> powerpc with respect to ELF loading of binaries (see below). Seems to
>> be related to recent MAP_FIXED_SAFE (or MAP_FIXED_NOREPLACE as seen
>> now in the code). IIUC (have not been following the series last month)
>> MAP_FIXED_NOREPLACE will fail an allocation request if the hint address
>> cannot be reserve instead of changing existing mappings.
> Correct
> 
>> Is it possible
>> that ELF loading needs to be fixed at a higher level to deal with these
>> new possible mmap() failures because of MAP_FIXED_NOREPLACE ?
> 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.

[   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
[   23.426089] 9151 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   23.426232] requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.429048] 9154 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   23.429196] requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.482766] 9164 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   23.482904] requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.485849] 9167 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   23.485945] requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   76.041836] 9262 (hostname): Uhuuh, elf segment at 0000000010020000 requested but the memory is mapped already
[   76.041965] requested [10020000, 10030000] mapped [10020000, 10030000] 100073 anon
[   76.207197] 9285 (pkg-config): Uhuuh, elf segment at 0000000010020000 requested but the memory is mapped already
[   76.207326] requested [10020000, 10030000] mapped [10020000, 10030000] 100073 anon
[   76.371073] 9299 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
[   76.371165] requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon


I have fixed/changed the debug patch a bit


diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index d8c5657..a43eccaa 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -372,11 +372,35 @@ 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))
+       if ((type & MAP_FIXED_NOREPLACE) && BAD_ADDR(map_addr)) {
+               struct vm_area_struct *vma;
+               unsigned long end;
+
+               if (total_size)
+                       end = addr + total_size;
+               else
+                       end = addr + size;
+
                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);

+               vma = find_vma(current->mm, addr);
+               if (vma && vma->vm_start <= addr) {
+                       pr_info("requested [%lx, %lx] mapped [%lx, %lx] %lx ", addr, end,
+                                       vma->vm_start, vma->vm_end, vma->vm_flags);
+                       if (!vma->vm_file) {
+                               pr_cont("anon\n");
+                       } else {
+                               char path[512];
+                               char *p = file_path(vma->vm_file, path, sizeof(path));
+                               if (IS_ERR(p))
+                                       p = "?";
+                               pr_cont("\"%s\"\n", kbasename(p));
+                       }
+                       dump_stack();
+               }
+       }
        return(map_addr);
 }




--
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>

^ permalink raw reply related	[flat|nested] 82+ messages in thread

* ppc elf_map breakage with MAP_FIXED_NOREPLACE (was: Re: mmotm 2018-01-04-16-19 uploaded)
  2018-01-07  6:49       ` Anshuman Khandual
@ 2018-01-07  9:02         ` Michal Hocko
  -1 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-07  9:02 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, broonie

On Sun 07-01-18 12:19:32, Anshuman Khandual wrote:
> On 01/05/2018 02:16 PM, Michal Hocko wrote:
[...]
> > 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?

> [   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.

> [   23.426089] 9151 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
> [   23.426232] requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
> [   23.429048] 9154 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
> [   23.429196] requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
> [   23.482766] 9164 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
> [   23.482904] requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
> [   23.485849] 9167 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
> [   23.485945] requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
> [   76.041836] 9262 (hostname): Uhuuh, elf segment at 0000000010020000 requested but the memory is mapped already
> [   76.041965] requested [10020000, 10030000] mapped [10020000, 10030000] 100073 anon
> [   76.207197] 9285 (pkg-config): Uhuuh, elf segment at 0000000010020000 requested but the memory is mapped already
> [   76.207326] requested [10020000, 10030000] mapped [10020000, 10030000] 100073 anon
> [   76.371073] 9299 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
> [   76.371165] requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
> 
> 
> I have fixed/changed the debug patch a bit
> 
> 
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index d8c5657..a43eccaa 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -372,11 +372,35 @@ 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))
> +       if ((type & MAP_FIXED_NOREPLACE) && BAD_ADDR(map_addr)) {
> +               struct vm_area_struct *vma;
> +               unsigned long end;
> +
> +               if (total_size)
> +                       end = addr + total_size;
> +               else
> +                       end = addr + size;
> +
>                 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);
> 
> +               vma = find_vma(current->mm, addr);
> +               if (vma && vma->vm_start <= addr) {
> +                       pr_info("requested [%lx, %lx] mapped [%lx, %lx] %lx ", addr, end,
> +                                       vma->vm_start, vma->vm_end, vma->vm_flags);
> +                       if (!vma->vm_file) {
> +                               pr_cont("anon\n");
> +                       } else {
> +                               char path[512];
> +                               char *p = file_path(vma->vm_file, path, sizeof(path));
> +                               if (IS_ERR(p))
> +                                       p = "?";
> +                               pr_cont("\"%s\"\n", kbasename(p));
> +                       }
> +                       dump_stack();
> +               }
> +       }
>         return(map_addr);
>  }
> 
> 
> 

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* ppc elf_map breakage with MAP_FIXED_NOREPLACE (was: Re: mmotm 2018-01-04-16-19 uploaded)
@ 2018-01-07  9:02         ` Michal Hocko
  0 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-07  9:02 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, broonie

On Sun 07-01-18 12:19:32, Anshuman Khandual wrote:
> On 01/05/2018 02:16 PM, Michal Hocko wrote:
[...]
> > 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?

> [   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.

> [   23.426089] 9151 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
> [   23.426232] requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
> [   23.429048] 9154 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
> [   23.429196] requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
> [   23.482766] 9164 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
> [   23.482904] requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
> [   23.485849] 9167 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
> [   23.485945] requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
> [   76.041836] 9262 (hostname): Uhuuh, elf segment at 0000000010020000 requested but the memory is mapped already
> [   76.041965] requested [10020000, 10030000] mapped [10020000, 10030000] 100073 anon
> [   76.207197] 9285 (pkg-config): Uhuuh, elf segment at 0000000010020000 requested but the memory is mapped already
> [   76.207326] requested [10020000, 10030000] mapped [10020000, 10030000] 100073 anon
> [   76.371073] 9299 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already
> [   76.371165] requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
> 
> 
> I have fixed/changed the debug patch a bit
> 
> 
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index d8c5657..a43eccaa 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -372,11 +372,35 @@ 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))
> +       if ((type & MAP_FIXED_NOREPLACE) && BAD_ADDR(map_addr)) {
> +               struct vm_area_struct *vma;
> +               unsigned long end;
> +
> +               if (total_size)
> +                       end = addr + total_size;
> +               else
> +                       end = addr + size;
> +
>                 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);
> 
> +               vma = find_vma(current->mm, addr);
> +               if (vma && vma->vm_start <= addr) {
> +                       pr_info("requested [%lx, %lx] mapped [%lx, %lx] %lx ", addr, end,
> +                                       vma->vm_start, vma->vm_end, vma->vm_flags);
> +                       if (!vma->vm_file) {
> +                               pr_cont("anon\n");
> +                       } else {
> +                               char path[512];
> +                               char *p = file_path(vma->vm_file, path, sizeof(path));
> +                               if (IS_ERR(p))
> +                                       p = "?";
> +                               pr_cont("\"%s\"\n", kbasename(p));
> +                       }
> +                       dump_stack();
> +               }
> +       }
>         return(map_addr);
>  }
> 
> 
> 

-- 
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE (was: Re: mmotm 2018-01-04-16-19 uploaded)
  2018-01-07  9:02         ` Michal Hocko
@ 2018-01-07 11:26           ` Michael Ellerman
  -1 siblings, 0 replies; 82+ messages in thread
From: Michael Ellerman @ 2018-01-07 11:26 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, broonie

Michal Hocko <mhocko@kernel.org> writes:

> On Sun 07-01-18 12:19:32, Anshuman Khandual wrote:
>> On 01/05/2018 02:16 PM, Michal Hocko wrote:
> [...]
>> > 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?
>
>> [   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.

cheers

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE (was: Re: mmotm 2018-01-04-16-19 uploaded)
@ 2018-01-07 11:26           ` Michael Ellerman
  0 siblings, 0 replies; 82+ messages in thread
From: Michael Ellerman @ 2018-01-07 11:26 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, broonie

Michal Hocko <mhocko@kernel.org> writes:

> On Sun 07-01-18 12:19:32, Anshuman Khandual wrote:
>> On 01/05/2018 02:16 PM, Michal Hocko wrote:
> [...]
>> > 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?
>
>> [   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.

cheers

--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-07 11:26           ` Michael Ellerman
@ 2018-01-08  3:02             ` Anshuman Khandual
  -1 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-08  3:02 UTC (permalink / raw)
  To: Michael Ellerman, Michal Hocko, Anshuman Khandual
  Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, broonie

On 01/07/2018 04:56 PM, Michael Ellerman wrote:
> Michal Hocko <mhocko@kernel.org> writes:
> 
>> On Sun 07-01-18 12:19:32, Anshuman Khandual wrote:
>>> On 01/05/2018 02:16 PM, Michal Hocko wrote:
>> [...]
>>>> 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?
>>
>>> [   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.

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-08  3:02             ` Anshuman Khandual
  0 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-08  3:02 UTC (permalink / raw)
  To: Michael Ellerman, Michal Hocko, Anshuman Khandual
  Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, broonie

On 01/07/2018 04:56 PM, Michael Ellerman wrote:
> Michal Hocko <mhocko@kernel.org> writes:
> 
>> On Sun 07-01-18 12:19:32, Anshuman Khandual wrote:
>>> On 01/05/2018 02:16 PM, Michal Hocko wrote:
>> [...]
>>>> 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?
>>
>>> [   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.

--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-08  3:02             ` Anshuman Khandual
  (?)
@ 2018-01-08 22:12               ` Michael Ellerman
  -1 siblings, 0 replies; 82+ messages in thread
From: Michael Ellerman @ 2018-01-08 22:12 UTC (permalink / raw)
  To: Anshuman Khandual, Michal Hocko, Anshuman Khandual
  Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, broonie

Anshuman Khandual <khandual@linux.vnet.ibm.com> writes:

> On 01/07/2018 04:56 PM, Michael Ellerman wrote:
>> Michal Hocko <mhocko@kernel.org> writes:
>> 
>>> On Sun 07-01-18 12:19:32, Anshuman Khandual wrote:
>>>> On 01/05/2018 02:16 PM, Michal Hocko wrote:
>>> [...]
>>>>> 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?
>>>
>>>> [   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?

cheers

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-08 22:12               ` Michael Ellerman
  0 siblings, 0 replies; 82+ messages in thread
From: Michael Ellerman @ 2018-01-08 22:12 UTC (permalink / raw)
  To: Anshuman Khandual, Michal Hocko, Anshuman Khandual
  Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, broonie

Anshuman Khandual <khandual@linux.vnet.ibm.com> writes:

> On 01/07/2018 04:56 PM, Michael Ellerman wrote:
>> Michal Hocko <mhocko@kernel.org> writes:
>> 
>>> On Sun 07-01-18 12:19:32, Anshuman Khandual wrote:
>>>> On 01/05/2018 02:16 PM, Michal Hocko wrote:
>>> [...]
>>>>> 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?
>>>
>>>> [   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?

cheers

--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-08 22:12               ` Michael Ellerman
  0 siblings, 0 replies; 82+ messages in thread
From: Michael Ellerman @ 2018-01-08 22:12 UTC (permalink / raw)
  To: Anshuman Khandual, Michal Hocko
  Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, broonie

Anshuman Khandual <khandual@linux.vnet.ibm.com> writes:

> On 01/07/2018 04:56 PM, Michael Ellerman wrote:
>> Michal Hocko <mhocko@kernel.org> writes:
>> 
>>> On Sun 07-01-18 12:19:32, Anshuman Khandual wrote:
>>>> On 01/05/2018 02:16 PM, Michal Hocko wrote:
>>> [...]
>>>>> 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?
>>>
>>>> [   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?

cheers

--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-08 22:12               ` Michael Ellerman
@ 2018-01-09 11:48                 ` Anshuman Khandual
  -1 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-09 11:48 UTC (permalink / raw)
  To: Michael Ellerman, Anshuman Khandual, Michal Hocko
  Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, broonie

On 01/09/2018 03:42 AM, Michael Ellerman wrote:
> Anshuman Khandual <khandual@linux.vnet.ibm.com> writes:
> 
>> On 01/07/2018 04:56 PM, Michael Ellerman wrote:
>>> Michal Hocko <mhocko@kernel.org> writes:
>>>
>>>> On Sun 07-01-18 12:19:32, Anshuman Khandual wrote:
>>>>> On 01/05/2018 02:16 PM, Michal Hocko wrote:
>>>> [...]
>>>>>> 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?
>>>>
>>>>> [   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.

=================================================================================================
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           PowerPC64
  Version:                           0x1
  Entry point address:               0x10002b70
  Start of program headers:          64 (bytes into file)
  Start of section headers:          135560 (bytes into file)
  Flags:                             0x2, abiv2
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         10
  Size of section headers:           64 (bytes)
  Number of section headers:         28
  Section header string table index: 27

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .interp           PROGBITS         0000000010000270  00000270
       0000000000000011  0000000000000000   A       0     0     1
  [ 2] .note.ABI-tag     NOTE             0000000010000284  00000284
       0000000000000020  0000000000000000   A       0     0     4
  [ 3] .note.gnu.build-i NOTE             00000000100002a4  000002a4
       0000000000000024  0000000000000000   A       0     0     4
  [ 4] .gnu.hash         GNU_HASH         00000000100002c8  000002c8
       000000000000003c  0000000000000000   A       5     0     8
  [ 5] .dynsym           DYNSYM           0000000010000308  00000308
       0000000000000a98  0000000000000018   A       6     1     8
  [ 6] .dynstr           STRTAB           0000000010000da0  00000da0
       0000000000000456  0000000000000000   A       0     0     1
  [ 7] .gnu.version      VERSYM           00000000100011f6  000011f6
       00000000000000e2  0000000000000002   A       5     0     2
  [ 8] .gnu.version_r    VERNEED          00000000100012d8  000012d8
       0000000000000020  0000000000000000   A       6     1     8
  [ 9] .rela.dyn         RELA             00000000100012f8  000012f8
       0000000000000168  0000000000000018   A       5     0     8
  [10] .rela.plt         RELA             0000000010001460  00001460
       0000000000000948  0000000000000018   A       5    22     8
  [11] .init             PROGBITS         0000000010001dc0  00001dc0
       000000000000004c  0000000000000000  AX       0     0     32
  [12] .text             PROGBITS         0000000010001e20  00001e20
       000000000000e550  0000000000000000  AX       0     0     32
  [13] .fini             PROGBITS         0000000010010370  00010370
       0000000000000024  0000000000000000  AX       0     0     4
  [14] .rodata           PROGBITS         0000000010010398  00010398
       0000000000001738  0000000000000000   A       0     0     8
  [15] .eh_frame_hdr     PROGBITS         0000000010011ad0  00011ad0
       00000000000004b4  0000000000000000   A       0     0     4
  [16] .eh_frame         PROGBITS         0000000010011f88  00011f88
       0000000000001b04  0000000000000000   A       0     0     8
  [17] .init_array       INIT_ARRAY       000000001002fd40  0001fd40
       0000000000000008  0000000000000000  WA       0     0     8
  [18] .fini_array       FINI_ARRAY       000000001002fd48  0001fd48
       0000000000000008  0000000000000000  WA       0     0     8
  [19] .jcr              PROGBITS         000000001002fd50  0001fd50
       0000000000000008  0000000000000000  WA       0     0     8
  [20] .dynamic          DYNAMIC          000000001002fd58  0001fd58
       0000000000000200  0000000000000010  WA       6     0     8
  [21] .got              PROGBITS         000000001002ff58  0001ff58
       00000000000000a8  0000000000000008  WA       0     0     8
  [22] .plt              NOBITS           0000000010030000  00020000
       0000000000000328  0000000000000008  WA       0     0     8
  [23] .data             PROGBITS         0000000010030328  00020328
       0000000000000384  0000000000000000  WA       0     0     8
  [24] .bss              NOBITS           00000000100306b0  000206ac
       0000000000009118  0000000000000000  WA       0     0     8
  [25] .gnu_debuglink    PROGBITS         0000000000000000  000206ac
       0000000000000010  0000000000000000           0     0     4
  [26] .gnu_debugdata    PROGBITS         0000000000000000  000206bc
       00000000000009c4  0000000000000000           0     0     1
  [27] .shstrtab         STRTAB           0000000000000000  00021080
       0000000000000104  0000000000000000           0     0     1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  p (processor specific)

There are no section groups in this file.

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000010000040 0x0000000010000040
                 0x0000000000000230 0x0000000000000230  R E    8
  INTERP         0x0000000000000270 0x0000000010000270 0x0000000010000270
                 0x0000000000000011 0x0000000000000011  R      1
      [Requesting program interpreter: /lib64/ld64.so.2]
  LOAD           0x0000000000000000 0x0000000010000000 0x0000000010000000
                 0x0000000000013a8c 0x0000000000013a8c  R E    10000
  LOAD           0x000000000001fd40 0x000000001002fd40 0x000000001002fd40
                 0x00000000000002c0 0x00000000000005e8  RW     10000
  LOAD           0x0000000000020328 0x0000000010030328 0x0000000010030328
                 0x0000000000000384 0x00000000000094a0  RW     10000
  DYNAMIC        0x000000000001fd58 0x000000001002fd58 0x000000001002fd58
                 0x0000000000000200 0x0000000000000200  RW     8
  NOTE           0x0000000000000284 0x0000000010000284 0x0000000010000284
                 0x0000000000000044 0x0000000000000044  R      4
  GNU_EH_FRAME   0x0000000000011ad0 0x0000000010011ad0 0x0000000010011ad0
                 0x00000000000004b4 0x00000000000004b4  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     10
  GNU_RELRO      0x000000000001fd40 0x000000001002fd40 0x000000001002fd40
                 0x00000000000002c0 0x00000000000002c0  R      1

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .text .fini .rodata .eh_frame_hdr .eh_frame 
   03     .init_array .fini_array .jcr .dynamic .got .plt 
   04     .data .bss 
   05     .dynamic 
   06     .note.ABI-tag .note.gnu.build-id 
   07     .eh_frame_hdr 
   08     
   09     .init_array .fini_array .jcr .dynamic .got 

Dynamic section at offset 0x1fd58 contains 27 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libselinux.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000c (INIT)               0x10001dd0
 0x000000000000000d (FINI)               0x10010370
 0x0000000000000019 (INIT_ARRAY)         0x1002fd40
 0x000000000000001b (INIT_ARRAYSZ)       8 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x1002fd48
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x100002c8
 0x0000000000000005 (STRTAB)             0x10000da0
 0x0000000000000006 (SYMTAB)             0x10000308
 0x000000000000000a (STRSZ)              1110 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000015 (DEBUG)              0x0
 0x0000000000000003 (PLTGOT)             0x10030000
 0x0000000000000002 (PLTRELSZ)           2376 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x10001460
 0x0000000070000000 (PPC64_GLINK)        0x100101a0
 0x0000000070000003 (PPC64_OPT)          0x0
 0x0000000000000007 (RELA)               0x100012f8
 0x0000000000000008 (RELASZ)             360 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x100012d8
 0x000000006fffffff (VERNEEDNUM)         1
 0x000000006ffffff0 (VERSYM)             0x100011f6
 0x0000000000000000 (NULL)               0x0

Relocation section '.rela.dyn' at offset 0x12f8 contains 15 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
00001002ff60  003400000026 R_PPC64_ADDR64    0000000000000000 __gmon_start__ + 0
00001002ff88  000c00000026 R_PPC64_ADDR64    0000000000000000 stderr@GLIBC_2.17 + 0
00001002ffb8  000c00000026 R_PPC64_ADDR64    0000000000000000 stderr@GLIBC_2.17 + 0
00001002ffd0  000c00000026 R_PPC64_ADDR64    0000000000000000 stderr@GLIBC_2.17 + 0
00001002fff0  000c00000026 R_PPC64_ADDR64    0000000000000000 stderr@GLIBC_2.17 + 0
00001002ff90  002100000026 R_PPC64_ADDR64    0000000000000000 stdout@GLIBC_2.17 + 0
00001002ffb0  002100000026 R_PPC64_ADDR64    0000000000000000 stdout@GLIBC_2.17 + 0
00001002ffd8  002100000026 R_PPC64_ADDR64    0000000000000000 stdout@GLIBC_2.17 + 0
00001002ffe8  002100000026 R_PPC64_ADDR64    0000000000000000 stdout@GLIBC_2.17 + 0
00001002fff8  002100000026 R_PPC64_ADDR64    0000000000000000 stdout@GLIBC_2.17 + 0
00001002ff98  000f00000026 R_PPC64_ADDR64    0000000000000000 optarg@GLIBC_2.17 + 0
00001002ffa0  001700000026 R_PPC64_ADDR64    0000000000000000 optind@GLIBC_2.17 + 0
00001002ffa8  002e00000026 R_PPC64_ADDR64    0000000000000000 stdin@GLIBC_2.17 + 0
00001002ffc8  002e00000026 R_PPC64_ADDR64    0000000000000000 stdin@GLIBC_2.17 + 0
00001002ffe0  002e00000026 R_PPC64_ADDR64    0000000000000000 stdin@GLIBC_2.17 + 0

Relocation section '.rela.plt' at offset 0x1460 contains 99 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000010030010  000100000015 R_PPC64_JMP_SLOT  0000000000000000 mbrtowc@GLIBC_2.17 + 0
000010030018  000200000015 R_PPC64_JMP_SLOT  0000000000000000 memcpy@GLIBC_2.17 + 0
000010030020  000300000015 R_PPC64_JMP_SLOT  0000000000000000 memmove@GLIBC_2.17 + 0
000010030028  000400000015 R_PPC64_JMP_SLOT  0000000000000000 strlen@GLIBC_2.17 + 0
000010030030  000500000015 R_PPC64_JMP_SLOT  0000000000000000 __sprintf_chk@GLIBC_2.17 + 0
000010030038  000600000015 R_PPC64_JMP_SLOT  0000000000000000 exit@GLIBC_2.17 + 0
000010030040  000700000015 R_PPC64_JMP_SLOT  0000000000000000 is_selinux_enabled + 0
000010030048  000800000015 R_PPC64_JMP_SLOT  0000000000000000 error@GLIBC_2.17 + 0
000010030050  000a00000015 R_PPC64_JMP_SLOT  0000000000000000 readlink@GLIBC_2.17 + 0
000010030058  000b00000015 R_PPC64_JMP_SLOT  0000000000000000 ftell@GLIBC_2.17 + 0
000010030060  000d00000015 R_PPC64_JMP_SLOT  0000000000000000 setvbuf@GLIBC_2.17 + 0
000010030068  000e00000015 R_PPC64_JMP_SLOT  0000000000000000 __fwriting@GLIBC_2.17 + 0
000010030070  001000000015 R_PPC64_JMP_SLOT  0000000000000000 re_set_syntax@GLIBC_2.17 + 0
000010030078  001100000015 R_PPC64_JMP_SLOT  0000000000000000 fileno@GLIBC_2.17 + 0
000010030080  001200000015 R_PPC64_JMP_SLOT  0000000000000000 fclose@GLIBC_2.17 + 0
000010030088  001300000015 R_PPC64_JMP_SLOT  0000000000000000 wctob@GLIBC_2.17 + 0
000010030090  001400000015 R_PPC64_JMP_SLOT  0000000000000000 nl_langinfo@GLIBC_2.17 + 0
000010030098  001500000015 R_PPC64_JMP_SLOT  0000000000000000 fopen@GLIBC_2.17 + 0
0000100300a0  001600000015 R_PPC64_JMP_SLOT  0000000000000000 malloc@GLIBC_2.17 + 0
0000100300a8  001800000015 R_PPC64_JMP_SLOT  0000000000000000 chmod@GLIBC_2.17 + 0
0000100300b0  001900000015 R_PPC64_JMP_SLOT  0000000000000000 getdelim@GLIBC_2.17 + 0
0000100300b8  001a00000015 R_PPC64_JMP_SLOT  0000000000000000 open@GLIBC_2.17 + 0
0000100300c0  001b00000015 R_PPC64_JMP_SLOT  0000000000000000 fgetfilecon + 0
0000100300c8  001c00000015 R_PPC64_JMP_SLOT  0000000000000000 _obstack_begin@GLIBC_2.17 + 0
0000100300d0  001d00000015 R_PPC64_JMP_SLOT  0000000000000000 popen@GLIBC_2.17 + 0
0000100300d8  001e00000015 R_PPC64_JMP_SLOT  0000000000000000 strncmp@GLIBC_2.17 + 0
0000100300e0  001f00000015 R_PPC64_JMP_SLOT  0000000000000000 bindtextdomain@GLIBC_2.17 + 0
0000100300e8  002000000015 R_PPC64_JMP_SLOT  0000000000000000 __libc_start_main@GLIBC_2.17 + 0
0000100300f0  002200000015 R_PPC64_JMP_SLOT  0000000000000000 strverscmp@GLIBC_2.17 + 0
0000100300f8  002300000015 R_PPC64_JMP_SLOT  0000000000000000 __printf_chk@GLIBC_2.17 + 0
000010030100  002400000015 R_PPC64_JMP_SLOT  0000000000000000 memset@GLIBC_2.17 + 0
000010030108  002500000015 R_PPC64_JMP_SLOT  0000000000000000 fdopen@GLIBC_2.17 + 0
000010030110  002600000015 R_PPC64_JMP_SLOT  0000000000000000 fchmod@GLIBC_2.17 + 0
000010030118  002700000015 R_PPC64_JMP_SLOT  0000000000000000 __vfprintf_chk@GLIBC_2.17 + 0
000010030120  002800000015 R_PPC64_JMP_SLOT  0000000000000000 calloc@GLIBC_2.17 + 0
000010030128  002900000015 R_PPC64_JMP_SLOT  0000000000000000 realloc@GLIBC_2.17 + 0
000010030130  002a00000015 R_PPC64_JMP_SLOT  0000000000000000 lgetfilecon + 0
000010030138  002b00000015 R_PPC64_JMP_SLOT  0000000000000000 re_search@GLIBC_2.17 + 0
000010030140  002c00000015 R_PPC64_JMP_SLOT  0000000000000000 __ctype_toupper_loc@GLIBC_2.17 + 0
000010030148  002d00000015 R_PPC64_JMP_SLOT  0000000000000000 rewind@GLIBC_2.17 + 0
000010030150  002f00000015 R_PPC64_JMP_SLOT  0000000000000000 fscanf@GLIBC_2.17 + 0
000010030158  003000000015 R_PPC64_JMP_SLOT  0000000000000000 strerror@GLIBC_2.17 + 0
000010030160  003100000015 R_PPC64_JMP_SLOT  0000000000000000 __stack_chk_fail@GLIBC_2.17 + 0
000010030168  003200000015 R_PPC64_JMP_SLOT  0000000000000000 close@GLIBC_2.17 + 0
000010030170  003300000015 R_PPC64_JMP_SLOT  0000000000000000 strrchr@GLIBC_2.17 + 0
000010030178  003400000015 R_PPC64_JMP_SLOT  0000000000000000 __gmon_start__ + 0
000010030180  003500000015 R_PPC64_JMP_SLOT  0000000000000000 btowc@GLIBC_2.17 + 0
000010030188  003600000015 R_PPC64_JMP_SLOT  0000000000000000 abort@GLIBC_2.17 + 0
000010030190  003700000015 R_PPC64_JMP_SLOT  0000000000000000 mkostemp@GLIBC_2.17 + 0
000010030198  003800000015 R_PPC64_JMP_SLOT  0000000000000000 re_compile_pattern@GLIBC_2.17 + 0
0000100301a0  003900000015 R_PPC64_JMP_SLOT  0000000000000000 getfilecon + 0
0000100301a8  003a00000015 R_PPC64_JMP_SLOT  0000000000000000 mbsinit@GLIBC_2.17 + 0
0000100301b0  003b00000015 R_PPC64_JMP_SLOT  0000000000000000 __overflow@GLIBC_2.17 + 0
0000100301b8  003c00000015 R_PPC64_JMP_SLOT  0000000000000000 fread_unlocked@GLIBC_2.17 + 0
0000100301c0  003d00000015 R_PPC64_JMP_SLOT  0000000000000000 memcmp@GLIBC_2.17 + 0
0000100301c8  003e00000015 R_PPC64_JMP_SLOT  0000000000000000 textdomain@GLIBC_2.17 + 0
0000100301d0  003f00000015 R_PPC64_JMP_SLOT  0000000000000000 setfscreatecon + 0
0000100301d8  004000000015 R_PPC64_JMP_SLOT  0000000000000000 _IO_putc@GLIBC_2.17 + 0
0000100301e0  004100000015 R_PPC64_JMP_SLOT  0000000000000000 getopt_long@GLIBC_2.17 + 0
0000100301e8  004200000015 R_PPC64_JMP_SLOT  0000000000000000 __fprintf_chk@GLIBC_2.17 + 0
0000100301f0  004300000015 R_PPC64_JMP_SLOT  0000000000000000 strcmp@GLIBC_2.17 + 0
0000100301f8  004400000015 R_PPC64_JMP_SLOT  0000000000000000 __ctype_b_loc@GLIBC_2.17 + 0
000010030200  004500000015 R_PPC64_JMP_SLOT  0000000000000000 strtol@GLIBC_2.17 + 0
000010030208  004600000015 R_PPC64_JMP_SLOT  0000000000000000 fread@GLIBC_2.17 + 0
000010030210  006d00000015 R_PPC64_JMP_SLOT  0000000010010360 free@GLIBC_2.17 + 0
000010030218  004700000015 R_PPC64_JMP_SLOT  0000000000000000 ungetc@GLIBC_2.17 + 0
000010030220  004800000015 R_PPC64_JMP_SLOT  0000000000000000 __ctype_get_mb_cur_max@GLIBC_2.17 + 0
000010030228  004900000015 R_PPC64_JMP_SLOT  0000000000000000 strchr@GLIBC_2.17 + 0
000010030230  004a00000015 R_PPC64_JMP_SLOT  0000000000000000 rename@GLIBC_2.17 + 0
000010030238  004b00000015 R_PPC64_JMP_SLOT  0000000000000000 fwrite@GLIBC_2.17 + 0
000010030240  004c00000015 R_PPC64_JMP_SLOT  0000000000000000 clearerr@GLIBC_2.17 + 0
000010030248  004d00000015 R_PPC64_JMP_SLOT  0000000000000000 dcngettext@GLIBC_2.17 + 0
000010030250  004e00000015 R_PPC64_JMP_SLOT  0000000000000000 fflush@GLIBC_2.17 + 0
000010030258  004f00000015 R_PPC64_JMP_SLOT  0000000000000000 strcpy@GLIBC_2.17 + 0
000010030260  005000000015 R_PPC64_JMP_SLOT  0000000000000000 clearerr_unlocked@GLIBC_2.17 + 0
000010030268  005100000015 R_PPC64_JMP_SLOT  0000000000000000 __lxstat@GLIBC_2.17 + 0
000010030270  005200000015 R_PPC64_JMP_SLOT  0000000000000000 memchr@GLIBC_2.17 + 0
000010030278  005300000015 R_PPC64_JMP_SLOT  0000000000000000 isatty@GLIBC_2.17 + 0
000010030280  005500000015 R_PPC64_JMP_SLOT  0000000000000000 _obstack_newchunk@GLIBC_2.17 + 0
000010030288  005600000015 R_PPC64_JMP_SLOT  0000000000000000 __fxstat@GLIBC_2.17 + 0
000010030290  005700000015 R_PPC64_JMP_SLOT  0000000000000000 dcgettext@GLIBC_2.17 + 0
000010030298  005800000015 R_PPC64_JMP_SLOT  0000000000000000 freecon + 0
0000100302a0  005900000015 R_PPC64_JMP_SLOT  0000000000000000 fputs_unlocked@GLIBC_2.17 + 0
0000100302a8  005a00000015 R_PPC64_JMP_SLOT  0000000000000000 strncpy@GLIBC_2.17 + 0
0000100302b0  005b00000015 R_PPC64_JMP_SLOT  0000000000000000 pclose@GLIBC_2.17 + 0
0000100302b8  005d00000015 R_PPC64_JMP_SLOT  0000000000000000 towupper@GLIBC_2.17 + 0
0000100302c0  005e00000015 R_PPC64_JMP_SLOT  0000000000000000 iswprint@GLIBC_2.17 + 0
0000100302c8  005f00000015 R_PPC64_JMP_SLOT  0000000000000000 umask@GLIBC_2.17 + 0
0000100302d0  006000000015 R_PPC64_JMP_SLOT  0000000000000000 getfscreatecon + 0
0000100302d8  006100000015 R_PPC64_JMP_SLOT  0000000000000000 __errno_location@GLIBC_2.17 + 0
0000100302e0  006200000015 R_PPC64_JMP_SLOT  0000000000000000 getenv@GLIBC_2.17 + 0
0000100302e8  006300000015 R_PPC64_JMP_SLOT  0000000000000000 __memmove_chk@GLIBC_2.17 + 0
0000100302f0  006400000015 R_PPC64_JMP_SLOT  0000000000000000 unlink@GLIBC_2.17 + 0
0000100302f8  006500000015 R_PPC64_JMP_SLOT  0000000000000000 fchown@GLIBC_2.17 + 0
000010030300  006600000015 R_PPC64_JMP_SLOT  0000000000000000 towlower@GLIBC_2.17 + 0
000010030308  006700000015 R_PPC64_JMP_SLOT  0000000000000000 __uflow@GLIBC_2.17 + 0
000010030310  006800000015 R_PPC64_JMP_SLOT  0000000000000000 setlocale@GLIBC_2.17 + 0
000010030318  006900000015 R_PPC64_JMP_SLOT  0000000000000000 ferror@GLIBC_2.17 + 0
000010030320  006a00000015 R_PPC64_JMP_SLOT  0000000000000000 wcrtomb@GLIBC_2.17 + 0

The decoding of unwind sections for machine type PowerPC64 is not currently supported.

Symbol table '.dynsym' contains 113 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND mbrtowc@GLIBC_2.17 (2)
     2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memcpy@GLIBC_2.17 (2)
     3: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memmove@GLIBC_2.17 (2)
     4: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strlen@GLIBC_2.17 (2)
     5: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __sprintf_chk@GLIBC_2.17 (2)
     6: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND exit@GLIBC_2.17 (2)
     7: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND is_selinux_enabled
     8: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND error@GLIBC_2.17 (2)
     9: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterTMCloneTab
    10: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND readlink@GLIBC_2.17 (2)
    11: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND ftell@GLIBC_2.17 (2)
    12: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND stderr@GLIBC_2.17 (2)
    13: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND setvbuf@GLIBC_2.17 (2)
    14: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __fwriting@GLIBC_2.17 (2)
    15: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND optarg@GLIBC_2.17 (2)
    16: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND re_set_syntax@GLIBC_2.17 (2)
    17: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fileno@GLIBC_2.17 (2)
    18: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fclose@GLIBC_2.17 (2)
    19: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND wctob@GLIBC_2.17 (2)
    20: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND nl_langinfo@GLIBC_2.17 (2)
    21: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fopen@GLIBC_2.17 (2)
    22: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND malloc@GLIBC_2.17 (2)
    23: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND optind@GLIBC_2.17 (2)
    24: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND chmod@GLIBC_2.17 (2)
    25: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND getdelim@GLIBC_2.17 (2)
    26: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND open@GLIBC_2.17 (2)
    27: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fgetfilecon
    28: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _obstack_begin@GLIBC_2.17 (2)
    29: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND popen@GLIBC_2.17 (2)
    30: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strncmp@GLIBC_2.17 (2)
    31: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND bindtextdomain@GLIBC_2.17 (2)
    32: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.17 (2)
    33: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND stdout@GLIBC_2.17 (2)
    34: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strverscmp@GLIBC_2.17 (2)
    35: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __printf_chk@GLIBC_2.17 (2)
    36: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memset@GLIBC_2.17 (2)
    37: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fdopen@GLIBC_2.17 (2)
    38: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fchmod@GLIBC_2.17 (2)
    39: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __vfprintf_chk@GLIBC_2.17 (2)
    40: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND calloc@GLIBC_2.17 (2)
    41: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND realloc@GLIBC_2.17 (2)
    42: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND lgetfilecon
    43: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND re_search@GLIBC_2.17 (2)
    44: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __ctype_toupper_loc@GLIBC_2.17 (2)
    45: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND rewind@GLIBC_2.17 (2)
    46: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND stdin@GLIBC_2.17 (2)
    47: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fscanf@GLIBC_2.17 (2)
    48: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strerror@GLIBC_2.17 (2)
    49: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail@GLIBC_2.17 (2)
    50: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND close@GLIBC_2.17 (2)
    51: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strrchr@GLIBC_2.17 (2)
    52: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
    53: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND btowc@GLIBC_2.17 (2)
    54: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND abort@GLIBC_2.17 (2)
    55: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND mkostemp@GLIBC_2.17 (2)
    56: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND re_compile_pattern@GLIBC_2.17 (2)
    57: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND getfilecon
    58: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND mbsinit@GLIBC_2.17 (2)
    59: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __overflow@GLIBC_2.17 (2)
    60: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fread_unlocked@GLIBC_2.17 (2)
    61: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memcmp@GLIBC_2.17 (2)
    62: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND textdomain@GLIBC_2.17 (2)
    63: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND setfscreatecon
    64: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _IO_putc@GLIBC_2.17 (2)
    65: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND getopt_long@GLIBC_2.17 (2)
    66: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __fprintf_chk@GLIBC_2.17 (2)
    67: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strcmp@GLIBC_2.17 (2)
    68: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __ctype_b_loc@GLIBC_2.17 (2)
    69: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strtol@GLIBC_2.17 (2)
    70: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fread@GLIBC_2.17 (2)
    71: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND ungetc@GLIBC_2.17 (2)
    72: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __ctype_get_mb_cur_max@GLIBC_2.17 (2)
    73: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strchr@GLIBC_2.17 (2)
    74: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND rename@GLIBC_2.17 (2)
    75: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fwrite@GLIBC_2.17 (2)
    76: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND clearerr@GLIBC_2.17 (2)
    77: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dcngettext@GLIBC_2.17 (2)
    78: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fflush@GLIBC_2.17 (2)
    79: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strcpy@GLIBC_2.17 (2)
    80: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND clearerr_unlocked@GLIBC_2.17 (2)
    81: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __lxstat@GLIBC_2.17 (2)
    82: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memchr@GLIBC_2.17 (2)
    83: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND isatty@GLIBC_2.17 (2)
    84: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _Jv_RegisterClasses
    85: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _obstack_newchunk@GLIBC_2.17 (2)
    86: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __fxstat@GLIBC_2.17 (2)
    87: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dcgettext@GLIBC_2.17 (2)
    88: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND freecon
    89: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fputs_unlocked@GLIBC_2.17 (2)
    90: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strncpy@GLIBC_2.17 (2)
    91: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND pclose@GLIBC_2.17 (2)
    92: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_registerTMCloneTable
    93: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND towupper@GLIBC_2.17 (2)
    94: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND iswprint@GLIBC_2.17 (2)
    95: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND umask@GLIBC_2.17 (2)
    96: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND getfscreatecon
    97: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __errno_location@GLIBC_2.17 (2)
    98: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND getenv@GLIBC_2.17 (2)
    99: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __memmove_chk@GLIBC_2.17 (2)
   100: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND unlink@GLIBC_2.17 (2)
   101: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fchown@GLIBC_2.17 (2)
   102: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND towlower@GLIBC_2.17 (2)
   103: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __uflow@GLIBC_2.17 (2)
   104: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND setlocale@GLIBC_2.17 (2)
   105: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND ferror@GLIBC_2.17 (2)
   106: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND wcrtomb@GLIBC_2.17 (2)
   107: 00000000100306ac     0 NOTYPE  GLOBAL DEFAULT   23 _edata
   108: 00000000100397c8     0 NOTYPE  GLOBAL DEFAULT   24 _end
   109: 0000000010010360     0 FUNC    GLOBAL DEFAULT  UND free@GLIBC_2.17 (2)
   110: 00000000100306ac     0 NOTYPE  GLOBAL DEFAULT   24 __bss_start
   111: 0000000010001dd0     0 FUNC    GLOBAL DEFAULT [<localentry>: 8]    11 _init
   112: 0000000010010370     0 FUNC    GLOBAL DEFAULT [<localentry>: 8]    13 _fini

Histogram for `.gnu.hash' bucket list length (total of 3 buckets):
 Length  Number     % of total  Coverage
      0  0          (  0.0%)
      1  1          ( 33.3%)     16.7%
      2  1          ( 33.3%)     50.0%
      3  1          ( 33.3%)    100.0%

Version symbols section '.gnu.version' contains 113 entries:
 Addr: 00000000100011f6  Offset: 0x0011f6  Link: 5 (.dynsym)
  000:   0 (*local*)       2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  004:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    0 (*local*)    
  008:   2 (GLIBC_2.17)    0 (*local*)       2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  00c:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  010:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  014:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  018:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    0 (*local*)    
  01c:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  020:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  024:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  028:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    0 (*local*)       2 (GLIBC_2.17) 
  02c:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  030:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  034:   0 (*local*)       2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  038:   2 (GLIBC_2.17)    0 (*local*)       2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  03c:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    0 (*local*)    
  040:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  044:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  048:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  04c:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  050:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  054:   0 (*local*)       2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  058:   0 (*local*)       2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  05c:   0 (*local*)       2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  060:   0 (*local*)       2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  064:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  068:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    1 (*global*)   
  06c:   1 (*global*)      2 (GLIBC_2.17)    1 (*global*)      1 (*global*)   
  070:   1 (*global*)   

Version needs section '.gnu.version_r' contains 1 entries:
 Addr: 0x00000000100012d8  Offset: 0x0012d8  Link: 6 (.dynstr)
  000000: Version: 1  File: libc.so.6  Cnt: 1
  0x0010:   Name: GLIBC_2.17  Flags: none  Version: 2

Displaying notes found at file offset 0x00000284 with length 0x00000020:
  Owner                 Data size	Description
  GNU                  0x00000010	NT_GNU_ABI_TAG (ABI version tag)
    OS: Linux, ABI: 2.6.32

Displaying notes found at file offset 0x000002a4 with length 0x00000024:
  Owner                 Data size	Description
  GNU                  0x00000014	NT_GNU_BUILD_ID (unique build ID bitstring)
    Build ID: a6c7b5f6f5cf4174f94bc7568ca07cfd81ee4443
=================================================================================================

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-09 11:48                 ` Anshuman Khandual
  0 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-09 11:48 UTC (permalink / raw)
  To: Michael Ellerman, Anshuman Khandual, Michal Hocko
  Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, broonie

On 01/09/2018 03:42 AM, Michael Ellerman wrote:
> Anshuman Khandual <khandual@linux.vnet.ibm.com> writes:
> 
>> On 01/07/2018 04:56 PM, Michael Ellerman wrote:
>>> Michal Hocko <mhocko@kernel.org> writes:
>>>
>>>> On Sun 07-01-18 12:19:32, Anshuman Khandual wrote:
>>>>> On 01/05/2018 02:16 PM, Michal Hocko wrote:
>>>> [...]
>>>>>> 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?
>>>>
>>>>> [   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.

=================================================================================================
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           PowerPC64
  Version:                           0x1
  Entry point address:               0x10002b70
  Start of program headers:          64 (bytes into file)
  Start of section headers:          135560 (bytes into file)
  Flags:                             0x2, abiv2
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         10
  Size of section headers:           64 (bytes)
  Number of section headers:         28
  Section header string table index: 27

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .interp           PROGBITS         0000000010000270  00000270
       0000000000000011  0000000000000000   A       0     0     1
  [ 2] .note.ABI-tag     NOTE             0000000010000284  00000284
       0000000000000020  0000000000000000   A       0     0     4
  [ 3] .note.gnu.build-i NOTE             00000000100002a4  000002a4
       0000000000000024  0000000000000000   A       0     0     4
  [ 4] .gnu.hash         GNU_HASH         00000000100002c8  000002c8
       000000000000003c  0000000000000000   A       5     0     8
  [ 5] .dynsym           DYNSYM           0000000010000308  00000308
       0000000000000a98  0000000000000018   A       6     1     8
  [ 6] .dynstr           STRTAB           0000000010000da0  00000da0
       0000000000000456  0000000000000000   A       0     0     1
  [ 7] .gnu.version      VERSYM           00000000100011f6  000011f6
       00000000000000e2  0000000000000002   A       5     0     2
  [ 8] .gnu.version_r    VERNEED          00000000100012d8  000012d8
       0000000000000020  0000000000000000   A       6     1     8
  [ 9] .rela.dyn         RELA             00000000100012f8  000012f8
       0000000000000168  0000000000000018   A       5     0     8
  [10] .rela.plt         RELA             0000000010001460  00001460
       0000000000000948  0000000000000018   A       5    22     8
  [11] .init             PROGBITS         0000000010001dc0  00001dc0
       000000000000004c  0000000000000000  AX       0     0     32
  [12] .text             PROGBITS         0000000010001e20  00001e20
       000000000000e550  0000000000000000  AX       0     0     32
  [13] .fini             PROGBITS         0000000010010370  00010370
       0000000000000024  0000000000000000  AX       0     0     4
  [14] .rodata           PROGBITS         0000000010010398  00010398
       0000000000001738  0000000000000000   A       0     0     8
  [15] .eh_frame_hdr     PROGBITS         0000000010011ad0  00011ad0
       00000000000004b4  0000000000000000   A       0     0     4
  [16] .eh_frame         PROGBITS         0000000010011f88  00011f88
       0000000000001b04  0000000000000000   A       0     0     8
  [17] .init_array       INIT_ARRAY       000000001002fd40  0001fd40
       0000000000000008  0000000000000000  WA       0     0     8
  [18] .fini_array       FINI_ARRAY       000000001002fd48  0001fd48
       0000000000000008  0000000000000000  WA       0     0     8
  [19] .jcr              PROGBITS         000000001002fd50  0001fd50
       0000000000000008  0000000000000000  WA       0     0     8
  [20] .dynamic          DYNAMIC          000000001002fd58  0001fd58
       0000000000000200  0000000000000010  WA       6     0     8
  [21] .got              PROGBITS         000000001002ff58  0001ff58
       00000000000000a8  0000000000000008  WA       0     0     8
  [22] .plt              NOBITS           0000000010030000  00020000
       0000000000000328  0000000000000008  WA       0     0     8
  [23] .data             PROGBITS         0000000010030328  00020328
       0000000000000384  0000000000000000  WA       0     0     8
  [24] .bss              NOBITS           00000000100306b0  000206ac
       0000000000009118  0000000000000000  WA       0     0     8
  [25] .gnu_debuglink    PROGBITS         0000000000000000  000206ac
       0000000000000010  0000000000000000           0     0     4
  [26] .gnu_debugdata    PROGBITS         0000000000000000  000206bc
       00000000000009c4  0000000000000000           0     0     1
  [27] .shstrtab         STRTAB           0000000000000000  00021080
       0000000000000104  0000000000000000           0     0     1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  p (processor specific)

There are no section groups in this file.

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000010000040 0x0000000010000040
                 0x0000000000000230 0x0000000000000230  R E    8
  INTERP         0x0000000000000270 0x0000000010000270 0x0000000010000270
                 0x0000000000000011 0x0000000000000011  R      1
      [Requesting program interpreter: /lib64/ld64.so.2]
  LOAD           0x0000000000000000 0x0000000010000000 0x0000000010000000
                 0x0000000000013a8c 0x0000000000013a8c  R E    10000
  LOAD           0x000000000001fd40 0x000000001002fd40 0x000000001002fd40
                 0x00000000000002c0 0x00000000000005e8  RW     10000
  LOAD           0x0000000000020328 0x0000000010030328 0x0000000010030328
                 0x0000000000000384 0x00000000000094a0  RW     10000
  DYNAMIC        0x000000000001fd58 0x000000001002fd58 0x000000001002fd58
                 0x0000000000000200 0x0000000000000200  RW     8
  NOTE           0x0000000000000284 0x0000000010000284 0x0000000010000284
                 0x0000000000000044 0x0000000000000044  R      4
  GNU_EH_FRAME   0x0000000000011ad0 0x0000000010011ad0 0x0000000010011ad0
                 0x00000000000004b4 0x00000000000004b4  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     10
  GNU_RELRO      0x000000000001fd40 0x000000001002fd40 0x000000001002fd40
                 0x00000000000002c0 0x00000000000002c0  R      1

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .text .fini .rodata .eh_frame_hdr .eh_frame 
   03     .init_array .fini_array .jcr .dynamic .got .plt 
   04     .data .bss 
   05     .dynamic 
   06     .note.ABI-tag .note.gnu.build-id 
   07     .eh_frame_hdr 
   08     
   09     .init_array .fini_array .jcr .dynamic .got 

Dynamic section at offset 0x1fd58 contains 27 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libselinux.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000c (INIT)               0x10001dd0
 0x000000000000000d (FINI)               0x10010370
 0x0000000000000019 (INIT_ARRAY)         0x1002fd40
 0x000000000000001b (INIT_ARRAYSZ)       8 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x1002fd48
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x100002c8
 0x0000000000000005 (STRTAB)             0x10000da0
 0x0000000000000006 (SYMTAB)             0x10000308
 0x000000000000000a (STRSZ)              1110 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000015 (DEBUG)              0x0
 0x0000000000000003 (PLTGOT)             0x10030000
 0x0000000000000002 (PLTRELSZ)           2376 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x10001460
 0x0000000070000000 (PPC64_GLINK)        0x100101a0
 0x0000000070000003 (PPC64_OPT)          0x0
 0x0000000000000007 (RELA)               0x100012f8
 0x0000000000000008 (RELASZ)             360 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x100012d8
 0x000000006fffffff (VERNEEDNUM)         1
 0x000000006ffffff0 (VERSYM)             0x100011f6
 0x0000000000000000 (NULL)               0x0

Relocation section '.rela.dyn' at offset 0x12f8 contains 15 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
00001002ff60  003400000026 R_PPC64_ADDR64    0000000000000000 __gmon_start__ + 0
00001002ff88  000c00000026 R_PPC64_ADDR64    0000000000000000 stderr@GLIBC_2.17 + 0
00001002ffb8  000c00000026 R_PPC64_ADDR64    0000000000000000 stderr@GLIBC_2.17 + 0
00001002ffd0  000c00000026 R_PPC64_ADDR64    0000000000000000 stderr@GLIBC_2.17 + 0
00001002fff0  000c00000026 R_PPC64_ADDR64    0000000000000000 stderr@GLIBC_2.17 + 0
00001002ff90  002100000026 R_PPC64_ADDR64    0000000000000000 stdout@GLIBC_2.17 + 0
00001002ffb0  002100000026 R_PPC64_ADDR64    0000000000000000 stdout@GLIBC_2.17 + 0
00001002ffd8  002100000026 R_PPC64_ADDR64    0000000000000000 stdout@GLIBC_2.17 + 0
00001002ffe8  002100000026 R_PPC64_ADDR64    0000000000000000 stdout@GLIBC_2.17 + 0
00001002fff8  002100000026 R_PPC64_ADDR64    0000000000000000 stdout@GLIBC_2.17 + 0
00001002ff98  000f00000026 R_PPC64_ADDR64    0000000000000000 optarg@GLIBC_2.17 + 0
00001002ffa0  001700000026 R_PPC64_ADDR64    0000000000000000 optind@GLIBC_2.17 + 0
00001002ffa8  002e00000026 R_PPC64_ADDR64    0000000000000000 stdin@GLIBC_2.17 + 0
00001002ffc8  002e00000026 R_PPC64_ADDR64    0000000000000000 stdin@GLIBC_2.17 + 0
00001002ffe0  002e00000026 R_PPC64_ADDR64    0000000000000000 stdin@GLIBC_2.17 + 0

Relocation section '.rela.plt' at offset 0x1460 contains 99 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000010030010  000100000015 R_PPC64_JMP_SLOT  0000000000000000 mbrtowc@GLIBC_2.17 + 0
000010030018  000200000015 R_PPC64_JMP_SLOT  0000000000000000 memcpy@GLIBC_2.17 + 0
000010030020  000300000015 R_PPC64_JMP_SLOT  0000000000000000 memmove@GLIBC_2.17 + 0
000010030028  000400000015 R_PPC64_JMP_SLOT  0000000000000000 strlen@GLIBC_2.17 + 0
000010030030  000500000015 R_PPC64_JMP_SLOT  0000000000000000 __sprintf_chk@GLIBC_2.17 + 0
000010030038  000600000015 R_PPC64_JMP_SLOT  0000000000000000 exit@GLIBC_2.17 + 0
000010030040  000700000015 R_PPC64_JMP_SLOT  0000000000000000 is_selinux_enabled + 0
000010030048  000800000015 R_PPC64_JMP_SLOT  0000000000000000 error@GLIBC_2.17 + 0
000010030050  000a00000015 R_PPC64_JMP_SLOT  0000000000000000 readlink@GLIBC_2.17 + 0
000010030058  000b00000015 R_PPC64_JMP_SLOT  0000000000000000 ftell@GLIBC_2.17 + 0
000010030060  000d00000015 R_PPC64_JMP_SLOT  0000000000000000 setvbuf@GLIBC_2.17 + 0
000010030068  000e00000015 R_PPC64_JMP_SLOT  0000000000000000 __fwriting@GLIBC_2.17 + 0
000010030070  001000000015 R_PPC64_JMP_SLOT  0000000000000000 re_set_syntax@GLIBC_2.17 + 0
000010030078  001100000015 R_PPC64_JMP_SLOT  0000000000000000 fileno@GLIBC_2.17 + 0
000010030080  001200000015 R_PPC64_JMP_SLOT  0000000000000000 fclose@GLIBC_2.17 + 0
000010030088  001300000015 R_PPC64_JMP_SLOT  0000000000000000 wctob@GLIBC_2.17 + 0
000010030090  001400000015 R_PPC64_JMP_SLOT  0000000000000000 nl_langinfo@GLIBC_2.17 + 0
000010030098  001500000015 R_PPC64_JMP_SLOT  0000000000000000 fopen@GLIBC_2.17 + 0
0000100300a0  001600000015 R_PPC64_JMP_SLOT  0000000000000000 malloc@GLIBC_2.17 + 0
0000100300a8  001800000015 R_PPC64_JMP_SLOT  0000000000000000 chmod@GLIBC_2.17 + 0
0000100300b0  001900000015 R_PPC64_JMP_SLOT  0000000000000000 getdelim@GLIBC_2.17 + 0
0000100300b8  001a00000015 R_PPC64_JMP_SLOT  0000000000000000 open@GLIBC_2.17 + 0
0000100300c0  001b00000015 R_PPC64_JMP_SLOT  0000000000000000 fgetfilecon + 0
0000100300c8  001c00000015 R_PPC64_JMP_SLOT  0000000000000000 _obstack_begin@GLIBC_2.17 + 0
0000100300d0  001d00000015 R_PPC64_JMP_SLOT  0000000000000000 popen@GLIBC_2.17 + 0
0000100300d8  001e00000015 R_PPC64_JMP_SLOT  0000000000000000 strncmp@GLIBC_2.17 + 0
0000100300e0  001f00000015 R_PPC64_JMP_SLOT  0000000000000000 bindtextdomain@GLIBC_2.17 + 0
0000100300e8  002000000015 R_PPC64_JMP_SLOT  0000000000000000 __libc_start_main@GLIBC_2.17 + 0
0000100300f0  002200000015 R_PPC64_JMP_SLOT  0000000000000000 strverscmp@GLIBC_2.17 + 0
0000100300f8  002300000015 R_PPC64_JMP_SLOT  0000000000000000 __printf_chk@GLIBC_2.17 + 0
000010030100  002400000015 R_PPC64_JMP_SLOT  0000000000000000 memset@GLIBC_2.17 + 0
000010030108  002500000015 R_PPC64_JMP_SLOT  0000000000000000 fdopen@GLIBC_2.17 + 0
000010030110  002600000015 R_PPC64_JMP_SLOT  0000000000000000 fchmod@GLIBC_2.17 + 0
000010030118  002700000015 R_PPC64_JMP_SLOT  0000000000000000 __vfprintf_chk@GLIBC_2.17 + 0
000010030120  002800000015 R_PPC64_JMP_SLOT  0000000000000000 calloc@GLIBC_2.17 + 0
000010030128  002900000015 R_PPC64_JMP_SLOT  0000000000000000 realloc@GLIBC_2.17 + 0
000010030130  002a00000015 R_PPC64_JMP_SLOT  0000000000000000 lgetfilecon + 0
000010030138  002b00000015 R_PPC64_JMP_SLOT  0000000000000000 re_search@GLIBC_2.17 + 0
000010030140  002c00000015 R_PPC64_JMP_SLOT  0000000000000000 __ctype_toupper_loc@GLIBC_2.17 + 0
000010030148  002d00000015 R_PPC64_JMP_SLOT  0000000000000000 rewind@GLIBC_2.17 + 0
000010030150  002f00000015 R_PPC64_JMP_SLOT  0000000000000000 fscanf@GLIBC_2.17 + 0
000010030158  003000000015 R_PPC64_JMP_SLOT  0000000000000000 strerror@GLIBC_2.17 + 0
000010030160  003100000015 R_PPC64_JMP_SLOT  0000000000000000 __stack_chk_fail@GLIBC_2.17 + 0
000010030168  003200000015 R_PPC64_JMP_SLOT  0000000000000000 close@GLIBC_2.17 + 0
000010030170  003300000015 R_PPC64_JMP_SLOT  0000000000000000 strrchr@GLIBC_2.17 + 0
000010030178  003400000015 R_PPC64_JMP_SLOT  0000000000000000 __gmon_start__ + 0
000010030180  003500000015 R_PPC64_JMP_SLOT  0000000000000000 btowc@GLIBC_2.17 + 0
000010030188  003600000015 R_PPC64_JMP_SLOT  0000000000000000 abort@GLIBC_2.17 + 0
000010030190  003700000015 R_PPC64_JMP_SLOT  0000000000000000 mkostemp@GLIBC_2.17 + 0
000010030198  003800000015 R_PPC64_JMP_SLOT  0000000000000000 re_compile_pattern@GLIBC_2.17 + 0
0000100301a0  003900000015 R_PPC64_JMP_SLOT  0000000000000000 getfilecon + 0
0000100301a8  003a00000015 R_PPC64_JMP_SLOT  0000000000000000 mbsinit@GLIBC_2.17 + 0
0000100301b0  003b00000015 R_PPC64_JMP_SLOT  0000000000000000 __overflow@GLIBC_2.17 + 0
0000100301b8  003c00000015 R_PPC64_JMP_SLOT  0000000000000000 fread_unlocked@GLIBC_2.17 + 0
0000100301c0  003d00000015 R_PPC64_JMP_SLOT  0000000000000000 memcmp@GLIBC_2.17 + 0
0000100301c8  003e00000015 R_PPC64_JMP_SLOT  0000000000000000 textdomain@GLIBC_2.17 + 0
0000100301d0  003f00000015 R_PPC64_JMP_SLOT  0000000000000000 setfscreatecon + 0
0000100301d8  004000000015 R_PPC64_JMP_SLOT  0000000000000000 _IO_putc@GLIBC_2.17 + 0
0000100301e0  004100000015 R_PPC64_JMP_SLOT  0000000000000000 getopt_long@GLIBC_2.17 + 0
0000100301e8  004200000015 R_PPC64_JMP_SLOT  0000000000000000 __fprintf_chk@GLIBC_2.17 + 0
0000100301f0  004300000015 R_PPC64_JMP_SLOT  0000000000000000 strcmp@GLIBC_2.17 + 0
0000100301f8  004400000015 R_PPC64_JMP_SLOT  0000000000000000 __ctype_b_loc@GLIBC_2.17 + 0
000010030200  004500000015 R_PPC64_JMP_SLOT  0000000000000000 strtol@GLIBC_2.17 + 0
000010030208  004600000015 R_PPC64_JMP_SLOT  0000000000000000 fread@GLIBC_2.17 + 0
000010030210  006d00000015 R_PPC64_JMP_SLOT  0000000010010360 free@GLIBC_2.17 + 0
000010030218  004700000015 R_PPC64_JMP_SLOT  0000000000000000 ungetc@GLIBC_2.17 + 0
000010030220  004800000015 R_PPC64_JMP_SLOT  0000000000000000 __ctype_get_mb_cur_max@GLIBC_2.17 + 0
000010030228  004900000015 R_PPC64_JMP_SLOT  0000000000000000 strchr@GLIBC_2.17 + 0
000010030230  004a00000015 R_PPC64_JMP_SLOT  0000000000000000 rename@GLIBC_2.17 + 0
000010030238  004b00000015 R_PPC64_JMP_SLOT  0000000000000000 fwrite@GLIBC_2.17 + 0
000010030240  004c00000015 R_PPC64_JMP_SLOT  0000000000000000 clearerr@GLIBC_2.17 + 0
000010030248  004d00000015 R_PPC64_JMP_SLOT  0000000000000000 dcngettext@GLIBC_2.17 + 0
000010030250  004e00000015 R_PPC64_JMP_SLOT  0000000000000000 fflush@GLIBC_2.17 + 0
000010030258  004f00000015 R_PPC64_JMP_SLOT  0000000000000000 strcpy@GLIBC_2.17 + 0
000010030260  005000000015 R_PPC64_JMP_SLOT  0000000000000000 clearerr_unlocked@GLIBC_2.17 + 0
000010030268  005100000015 R_PPC64_JMP_SLOT  0000000000000000 __lxstat@GLIBC_2.17 + 0
000010030270  005200000015 R_PPC64_JMP_SLOT  0000000000000000 memchr@GLIBC_2.17 + 0
000010030278  005300000015 R_PPC64_JMP_SLOT  0000000000000000 isatty@GLIBC_2.17 + 0
000010030280  005500000015 R_PPC64_JMP_SLOT  0000000000000000 _obstack_newchunk@GLIBC_2.17 + 0
000010030288  005600000015 R_PPC64_JMP_SLOT  0000000000000000 __fxstat@GLIBC_2.17 + 0
000010030290  005700000015 R_PPC64_JMP_SLOT  0000000000000000 dcgettext@GLIBC_2.17 + 0
000010030298  005800000015 R_PPC64_JMP_SLOT  0000000000000000 freecon + 0
0000100302a0  005900000015 R_PPC64_JMP_SLOT  0000000000000000 fputs_unlocked@GLIBC_2.17 + 0
0000100302a8  005a00000015 R_PPC64_JMP_SLOT  0000000000000000 strncpy@GLIBC_2.17 + 0
0000100302b0  005b00000015 R_PPC64_JMP_SLOT  0000000000000000 pclose@GLIBC_2.17 + 0
0000100302b8  005d00000015 R_PPC64_JMP_SLOT  0000000000000000 towupper@GLIBC_2.17 + 0
0000100302c0  005e00000015 R_PPC64_JMP_SLOT  0000000000000000 iswprint@GLIBC_2.17 + 0
0000100302c8  005f00000015 R_PPC64_JMP_SLOT  0000000000000000 umask@GLIBC_2.17 + 0
0000100302d0  006000000015 R_PPC64_JMP_SLOT  0000000000000000 getfscreatecon + 0
0000100302d8  006100000015 R_PPC64_JMP_SLOT  0000000000000000 __errno_location@GLIBC_2.17 + 0
0000100302e0  006200000015 R_PPC64_JMP_SLOT  0000000000000000 getenv@GLIBC_2.17 + 0
0000100302e8  006300000015 R_PPC64_JMP_SLOT  0000000000000000 __memmove_chk@GLIBC_2.17 + 0
0000100302f0  006400000015 R_PPC64_JMP_SLOT  0000000000000000 unlink@GLIBC_2.17 + 0
0000100302f8  006500000015 R_PPC64_JMP_SLOT  0000000000000000 fchown@GLIBC_2.17 + 0
000010030300  006600000015 R_PPC64_JMP_SLOT  0000000000000000 towlower@GLIBC_2.17 + 0
000010030308  006700000015 R_PPC64_JMP_SLOT  0000000000000000 __uflow@GLIBC_2.17 + 0
000010030310  006800000015 R_PPC64_JMP_SLOT  0000000000000000 setlocale@GLIBC_2.17 + 0
000010030318  006900000015 R_PPC64_JMP_SLOT  0000000000000000 ferror@GLIBC_2.17 + 0
000010030320  006a00000015 R_PPC64_JMP_SLOT  0000000000000000 wcrtomb@GLIBC_2.17 + 0

The decoding of unwind sections for machine type PowerPC64 is not currently supported.

Symbol table '.dynsym' contains 113 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND mbrtowc@GLIBC_2.17 (2)
     2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memcpy@GLIBC_2.17 (2)
     3: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memmove@GLIBC_2.17 (2)
     4: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strlen@GLIBC_2.17 (2)
     5: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __sprintf_chk@GLIBC_2.17 (2)
     6: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND exit@GLIBC_2.17 (2)
     7: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND is_selinux_enabled
     8: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND error@GLIBC_2.17 (2)
     9: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterTMCloneTab
    10: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND readlink@GLIBC_2.17 (2)
    11: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND ftell@GLIBC_2.17 (2)
    12: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND stderr@GLIBC_2.17 (2)
    13: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND setvbuf@GLIBC_2.17 (2)
    14: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __fwriting@GLIBC_2.17 (2)
    15: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND optarg@GLIBC_2.17 (2)
    16: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND re_set_syntax@GLIBC_2.17 (2)
    17: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fileno@GLIBC_2.17 (2)
    18: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fclose@GLIBC_2.17 (2)
    19: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND wctob@GLIBC_2.17 (2)
    20: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND nl_langinfo@GLIBC_2.17 (2)
    21: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fopen@GLIBC_2.17 (2)
    22: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND malloc@GLIBC_2.17 (2)
    23: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND optind@GLIBC_2.17 (2)
    24: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND chmod@GLIBC_2.17 (2)
    25: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND getdelim@GLIBC_2.17 (2)
    26: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND open@GLIBC_2.17 (2)
    27: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fgetfilecon
    28: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _obstack_begin@GLIBC_2.17 (2)
    29: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND popen@GLIBC_2.17 (2)
    30: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strncmp@GLIBC_2.17 (2)
    31: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND bindtextdomain@GLIBC_2.17 (2)
    32: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.17 (2)
    33: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND stdout@GLIBC_2.17 (2)
    34: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strverscmp@GLIBC_2.17 (2)
    35: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __printf_chk@GLIBC_2.17 (2)
    36: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memset@GLIBC_2.17 (2)
    37: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fdopen@GLIBC_2.17 (2)
    38: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fchmod@GLIBC_2.17 (2)
    39: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __vfprintf_chk@GLIBC_2.17 (2)
    40: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND calloc@GLIBC_2.17 (2)
    41: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND realloc@GLIBC_2.17 (2)
    42: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND lgetfilecon
    43: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND re_search@GLIBC_2.17 (2)
    44: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __ctype_toupper_loc@GLIBC_2.17 (2)
    45: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND rewind@GLIBC_2.17 (2)
    46: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND stdin@GLIBC_2.17 (2)
    47: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fscanf@GLIBC_2.17 (2)
    48: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strerror@GLIBC_2.17 (2)
    49: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail@GLIBC_2.17 (2)
    50: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND close@GLIBC_2.17 (2)
    51: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strrchr@GLIBC_2.17 (2)
    52: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
    53: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND btowc@GLIBC_2.17 (2)
    54: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND abort@GLIBC_2.17 (2)
    55: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND mkostemp@GLIBC_2.17 (2)
    56: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND re_compile_pattern@GLIBC_2.17 (2)
    57: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND getfilecon
    58: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND mbsinit@GLIBC_2.17 (2)
    59: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __overflow@GLIBC_2.17 (2)
    60: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fread_unlocked@GLIBC_2.17 (2)
    61: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memcmp@GLIBC_2.17 (2)
    62: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND textdomain@GLIBC_2.17 (2)
    63: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND setfscreatecon
    64: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _IO_putc@GLIBC_2.17 (2)
    65: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND getopt_long@GLIBC_2.17 (2)
    66: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __fprintf_chk@GLIBC_2.17 (2)
    67: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strcmp@GLIBC_2.17 (2)
    68: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __ctype_b_loc@GLIBC_2.17 (2)
    69: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strtol@GLIBC_2.17 (2)
    70: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fread@GLIBC_2.17 (2)
    71: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND ungetc@GLIBC_2.17 (2)
    72: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __ctype_get_mb_cur_max@GLIBC_2.17 (2)
    73: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strchr@GLIBC_2.17 (2)
    74: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND rename@GLIBC_2.17 (2)
    75: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fwrite@GLIBC_2.17 (2)
    76: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND clearerr@GLIBC_2.17 (2)
    77: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dcngettext@GLIBC_2.17 (2)
    78: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fflush@GLIBC_2.17 (2)
    79: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strcpy@GLIBC_2.17 (2)
    80: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND clearerr_unlocked@GLIBC_2.17 (2)
    81: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __lxstat@GLIBC_2.17 (2)
    82: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memchr@GLIBC_2.17 (2)
    83: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND isatty@GLIBC_2.17 (2)
    84: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _Jv_RegisterClasses
    85: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _obstack_newchunk@GLIBC_2.17 (2)
    86: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __fxstat@GLIBC_2.17 (2)
    87: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dcgettext@GLIBC_2.17 (2)
    88: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND freecon
    89: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fputs_unlocked@GLIBC_2.17 (2)
    90: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strncpy@GLIBC_2.17 (2)
    91: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND pclose@GLIBC_2.17 (2)
    92: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_registerTMCloneTable
    93: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND towupper@GLIBC_2.17 (2)
    94: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND iswprint@GLIBC_2.17 (2)
    95: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND umask@GLIBC_2.17 (2)
    96: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND getfscreatecon
    97: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __errno_location@GLIBC_2.17 (2)
    98: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND getenv@GLIBC_2.17 (2)
    99: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __memmove_chk@GLIBC_2.17 (2)
   100: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND unlink@GLIBC_2.17 (2)
   101: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fchown@GLIBC_2.17 (2)
   102: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND towlower@GLIBC_2.17 (2)
   103: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __uflow@GLIBC_2.17 (2)
   104: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND setlocale@GLIBC_2.17 (2)
   105: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND ferror@GLIBC_2.17 (2)
   106: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND wcrtomb@GLIBC_2.17 (2)
   107: 00000000100306ac     0 NOTYPE  GLOBAL DEFAULT   23 _edata
   108: 00000000100397c8     0 NOTYPE  GLOBAL DEFAULT   24 _end
   109: 0000000010010360     0 FUNC    GLOBAL DEFAULT  UND free@GLIBC_2.17 (2)
   110: 00000000100306ac     0 NOTYPE  GLOBAL DEFAULT   24 __bss_start
   111: 0000000010001dd0     0 FUNC    GLOBAL DEFAULT [<localentry>: 8]    11 _init
   112: 0000000010010370     0 FUNC    GLOBAL DEFAULT [<localentry>: 8]    13 _fini

Histogram for `.gnu.hash' bucket list length (total of 3 buckets):
 Length  Number     % of total  Coverage
      0  0          (  0.0%)
      1  1          ( 33.3%)     16.7%
      2  1          ( 33.3%)     50.0%
      3  1          ( 33.3%)    100.0%

Version symbols section '.gnu.version' contains 113 entries:
 Addr: 00000000100011f6  Offset: 0x0011f6  Link: 5 (.dynsym)
  000:   0 (*local*)       2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  004:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    0 (*local*)    
  008:   2 (GLIBC_2.17)    0 (*local*)       2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  00c:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  010:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  014:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  018:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    0 (*local*)    
  01c:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  020:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  024:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  028:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    0 (*local*)       2 (GLIBC_2.17) 
  02c:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  030:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  034:   0 (*local*)       2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  038:   2 (GLIBC_2.17)    0 (*local*)       2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  03c:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    0 (*local*)    
  040:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  044:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  048:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  04c:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  050:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  054:   0 (*local*)       2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  058:   0 (*local*)       2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  05c:   0 (*local*)       2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  060:   0 (*local*)       2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  064:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17) 
  068:   2 (GLIBC_2.17)    2 (GLIBC_2.17)    2 (GLIBC_2.17)    1 (*global*)   
  06c:   1 (*global*)      2 (GLIBC_2.17)    1 (*global*)      1 (*global*)   
  070:   1 (*global*)   

Version needs section '.gnu.version_r' contains 1 entries:
 Addr: 0x00000000100012d8  Offset: 0x0012d8  Link: 6 (.dynstr)
  000000: Version: 1  File: libc.so.6  Cnt: 1
  0x0010:   Name: GLIBC_2.17  Flags: none  Version: 2

Displaying notes found at file offset 0x00000284 with length 0x00000020:
  Owner                 Data size	Description
  GNU                  0x00000010	NT_GNU_ABI_TAG (ABI version tag)
    OS: Linux, ABI: 2.6.32

Displaying notes found at file offset 0x000002a4 with length 0x00000024:
  Owner                 Data size	Description
  GNU                  0x00000014	NT_GNU_BUILD_ID (unique build ID bitstring)
    Build ID: a6c7b5f6f5cf4174f94bc7568ca07cfd81ee4443
=================================================================================================

--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-09 11:48                 ` Anshuman Khandual
@ 2018-01-09 16:13                   ` Michal Hocko
  -1 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-09 16:13 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On Tue 09-01-18 17:18:38, Anshuman Khandual wrote:
> On 01/09/2018 03:42 AM, Michael Ellerman wrote:
> > Anshuman Khandual <khandual@linux.vnet.ibm.com> writes:
> > 
> >> On 01/07/2018 04:56 PM, Michael Ellerman wrote:
> >>> Michal Hocko <mhocko@kernel.org> writes:
> >>>
> >>>> On Sun 07-01-18 12:19:32, Anshuman Khandual wrote:
> >>>>> On 01/05/2018 02:16 PM, Michal Hocko wrote:
> >>>> [...]
> >>>>>> 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?
> >>>>
> >>>>> [   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

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-09 16:13                   ` Michal Hocko
  0 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-09 16:13 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On Tue 09-01-18 17:18:38, Anshuman Khandual wrote:
> On 01/09/2018 03:42 AM, Michael Ellerman wrote:
> > Anshuman Khandual <khandual@linux.vnet.ibm.com> writes:
> > 
> >> On 01/07/2018 04:56 PM, Michael Ellerman wrote:
> >>> Michal Hocko <mhocko@kernel.org> writes:
> >>>
> >>>> On Sun 07-01-18 12:19:32, Anshuman Khandual wrote:
> >>>>> On 01/05/2018 02:16 PM, Michal Hocko wrote:
> >>>> [...]
> >>>>>> 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?
> >>>>
> >>>>> [   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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-09 16:13                   ` Michal Hocko
@ 2018-01-11 10:08                     ` Anshuman Khandual
  -1 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-11 10:08 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On 01/09/2018 09:43 PM, Michal Hocko wrote:
> On Tue 09-01-18 17:18:38, Anshuman Khandual wrote:
>> On 01/09/2018 03:42 AM, Michael Ellerman wrote:
>>> Anshuman Khandual <khandual@linux.vnet.ibm.com> writes:
>>>
>>>> On 01/07/2018 04:56 PM, Michael Ellerman wrote:
>>>>> Michal Hocko <mhocko@kernel.org> writes:
>>>>>
>>>>>> On Sun 07-01-18 12:19:32, Anshuman Khandual wrote:
>>>>>>> On 01/05/2018 02:16 PM, Michal Hocko wrote:
>>>>>> [...]
>>>>>>>> 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?
>>>>>>
>>>>>>> [   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?

Not yet, will get back on this.

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-11 10:08                     ` Anshuman Khandual
  0 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-11 10:08 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On 01/09/2018 09:43 PM, Michal Hocko wrote:
> On Tue 09-01-18 17:18:38, Anshuman Khandual wrote:
>> On 01/09/2018 03:42 AM, Michael Ellerman wrote:
>>> Anshuman Khandual <khandual@linux.vnet.ibm.com> writes:
>>>
>>>> On 01/07/2018 04:56 PM, Michael Ellerman wrote:
>>>>> Michal Hocko <mhocko@kernel.org> writes:
>>>>>
>>>>>> On Sun 07-01-18 12:19:32, Anshuman Khandual wrote:
>>>>>>> On 01/05/2018 02:16 PM, Michal Hocko wrote:
>>>>>> [...]
>>>>>>>> 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?
>>>>>>
>>>>>>> [   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?

Not yet, will get back on this.

--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-11 10:08                     ` Anshuman Khandual
@ 2018-01-17  8:07                       ` Michal Hocko
  -1 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-17  8:07 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On Thu 11-01-18 15:38:37, Anshuman Khandual wrote:
> On 01/09/2018 09:43 PM, Michal Hocko wrote:
[...]
> > Did you manage to catch _who_ is requesting that anonymous mapping? Do
> > you need a help with the debugging patch?
> 
> Not yet, will get back on this.

ping?

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-17  8:07                       ` Michal Hocko
  0 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-17  8:07 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On Thu 11-01-18 15:38:37, Anshuman Khandual wrote:
> On 01/09/2018 09:43 PM, Michal Hocko wrote:
[...]
> > Did you manage to catch _who_ is requesting that anonymous mapping? Do
> > you need a help with the debugging patch?
> 
> Not yet, will get back on this.

ping?

-- 
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-17  8:07                       ` Michal Hocko
@ 2018-01-23 11:25                         ` Anshuman Khandual
  -1 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-23 11:25 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On 01/17/2018 01:37 PM, Michal Hocko wrote:
> On Thu 11-01-18 15:38:37, Anshuman Khandual wrote:
>> On 01/09/2018 09:43 PM, Michal Hocko wrote:
> [...]
>>> Did you manage to catch _who_ is requesting that anonymous mapping? Do
>>> you need a help with the debugging patch?
>>
>> Not yet, will get back on this.
> 
> ping?

Hey Michal,

Missed this thread, my apologies. This problem is happening only with
certain binaries like 'sed', 'tmux', 'hostname', 'pkg-config' etc. As
you had mentioned before the map request collision is happening on
[10030000, 10040000] and [10030000, 10040000] ranges only which is
just a single PAGE_SIZE. You asked previously that who might have
requested the anon mapping which is already present in there ? Would
not that be the same process itself ? I am bit confused. Would it be
helpful to trap all the mmap() requests from any of the binaries
and see where we might have created that anon mapping ?

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-23 11:25                         ` Anshuman Khandual
  0 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-23 11:25 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On 01/17/2018 01:37 PM, Michal Hocko wrote:
> On Thu 11-01-18 15:38:37, Anshuman Khandual wrote:
>> On 01/09/2018 09:43 PM, Michal Hocko wrote:
> [...]
>>> Did you manage to catch _who_ is requesting that anonymous mapping? Do
>>> you need a help with the debugging patch?
>>
>> Not yet, will get back on this.
> 
> ping?

Hey Michal,

Missed this thread, my apologies. This problem is happening only with
certain binaries like 'sed', 'tmux', 'hostname', 'pkg-config' etc. As
you had mentioned before the map request collision is happening on
[10030000, 10040000] and [10030000, 10040000] ranges only which is
just a single PAGE_SIZE. You asked previously that who might have
requested the anon mapping which is already present in there ? Would
not that be the same process itself ? I am bit confused. Would it be
helpful to trap all the mmap() requests from any of the binaries
and see where we might have created that anon mapping ?



--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-23 11:25                         ` Anshuman Khandual
@ 2018-01-23 12:45                           ` Michal Hocko
  -1 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-23 12:45 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On Tue 23-01-18 16:55:18, Anshuman Khandual wrote:
> On 01/17/2018 01:37 PM, Michal Hocko wrote:
> > On Thu 11-01-18 15:38:37, Anshuman Khandual wrote:
> >> On 01/09/2018 09:43 PM, Michal Hocko wrote:
> > [...]
> >>> Did you manage to catch _who_ is requesting that anonymous mapping? Do
> >>> you need a help with the debugging patch?
> >>
> >> Not yet, will get back on this.
> > 
> > ping?
> 
> Hey Michal,
> 
> Missed this thread, my apologies. This problem is happening only with
> certain binaries like 'sed', 'tmux', 'hostname', 'pkg-config' etc. As
> you had mentioned before the map request collision is happening on
> [10030000, 10040000] and [10030000, 10040000] ranges only which is
> just a single PAGE_SIZE. You asked previously that who might have
> requested the anon mapping which is already present in there ? Would
> not that be the same process itself ? I am bit confused.

We are early in the ELF loading. If we are mapping over an existing
mapping then we are effectivelly corrupting it. In other words exactly
what this patch tries to prevent. I fail to see what would be a relevant
anon mapping this early and why it would be colliding with elf
segements.

> Would it be
> helpful to trap all the mmap() requests from any of the binaries
> and see where we might have created that anon mapping ?

Yeah, that is exactly what I was suggesting. Sorry for not being clear
about that.

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-23 12:45                           ` Michal Hocko
  0 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-23 12:45 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On Tue 23-01-18 16:55:18, Anshuman Khandual wrote:
> On 01/17/2018 01:37 PM, Michal Hocko wrote:
> > On Thu 11-01-18 15:38:37, Anshuman Khandual wrote:
> >> On 01/09/2018 09:43 PM, Michal Hocko wrote:
> > [...]
> >>> Did you manage to catch _who_ is requesting that anonymous mapping? Do
> >>> you need a help with the debugging patch?
> >>
> >> Not yet, will get back on this.
> > 
> > ping?
> 
> Hey Michal,
> 
> Missed this thread, my apologies. This problem is happening only with
> certain binaries like 'sed', 'tmux', 'hostname', 'pkg-config' etc. As
> you had mentioned before the map request collision is happening on
> [10030000, 10040000] and [10030000, 10040000] ranges only which is
> just a single PAGE_SIZE. You asked previously that who might have
> requested the anon mapping which is already present in there ? Would
> not that be the same process itself ? I am bit confused.

We are early in the ELF loading. If we are mapping over an existing
mapping then we are effectivelly corrupting it. In other words exactly
what this patch tries to prevent. I fail to see what would be a relevant
anon mapping this early and why it would be colliding with elf
segements.

> Would it be
> helpful to trap all the mmap() requests from any of the binaries
> and see where we might have created that anon mapping ?

Yeah, that is exactly what I was suggesting. Sorry for not being clear
about that.

-- 
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-23 12:45                           ` Michal Hocko
@ 2018-01-23 15:58                             ` Anshuman Khandual
  -1 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-23 15:58 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On 01/23/2018 06:15 PM, Michal Hocko wrote:
> On Tue 23-01-18 16:55:18, Anshuman Khandual wrote:
>> On 01/17/2018 01:37 PM, Michal Hocko wrote:
>>> On Thu 11-01-18 15:38:37, Anshuman Khandual wrote:
>>>> On 01/09/2018 09:43 PM, Michal Hocko wrote:
>>> [...]
>>>>> Did you manage to catch _who_ is requesting that anonymous mapping? Do
>>>>> you need a help with the debugging patch?
>>>>
>>>> Not yet, will get back on this.
>>>
>>> ping?
>>
>> Hey Michal,
>>
>> Missed this thread, my apologies. This problem is happening only with
>> certain binaries like 'sed', 'tmux', 'hostname', 'pkg-config' etc. As
>> you had mentioned before the map request collision is happening on
>> [10030000, 10040000] and [10030000, 10040000] ranges only which is
>> just a single PAGE_SIZE. You asked previously that who might have
>> requested the anon mapping which is already present in there ? Would
>> not that be the same process itself ? I am bit confused.
> 
> We are early in the ELF loading. If we are mapping over an existing
> mapping then we are effectivelly corrupting it. In other words exactly
> what this patch tries to prevent. I fail to see what would be a relevant
> anon mapping this early and why it would be colliding with elf
> segements.
> 
>> Would it be
>> helpful to trap all the mmap() requests from any of the binaries
>> and see where we might have created that anon mapping ?
> 
> Yeah, that is exactly what I was suggesting. Sorry for not being clear
> about that.
> 

Tried to instrument just for the 'sed' binary and dont see any where
it actually requests the anon VMA which got hit when loading the ELF
section which is strange. All these requested flags here already has
MAP_FIXED_NOREPLACE (0x100000). Wondering from where the anon VMA
actually came from.

cat /sys/kernel/debug/tracing/trace | grep '10030000 10040000'

             sed-7579  [008] ....    10.358521: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-7583  [060] ....    10.358640: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8520  [059] ....    14.955216: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8802  [040] ....    23.063756: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8804  [051] ....    23.064434: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8828  [051] ....    23.334103: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8836  [066] .n..    23.369308: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8859  [013] ....    23.436563: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8868  [020] ....    23.484949: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8916  [066] ....    23.692761: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8936  [065] ....    23.860220: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8941  [066] ....    23.864280: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8946  [006] ....    23.868742: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8952  [056] ....    23.906065: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8969  [044] ....    24.199167: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8975  [005] ....    24.212314: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8980  [046] ....    24.215694: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8987  [028] ....    24.223261: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9001  [016] ....    24.247962: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9004  [048] ....    24.250521: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9007  [017] ....    24.253165: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9010  [005] ....    24.255651: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9013  [030] ....    24.258122: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9016  [004] ....    24.260814: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9020  [029] ....    24.266019: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9026  [003] .n..    24.269327: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9029  [053] ....    24.272223: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9032  [030] ....    24.274914: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9035  [068] ....    24.277492: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9038  [007] ....    24.280134: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9043  [065] ....    24.286741: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9046  [060] ....    24.289189: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9049  [018] ....    24.291915: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9052  [068] ....    24.294782: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9056  [044] ....    24.299412: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9059  [068] ....    24.302153: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9062  [055] ....    24.304719: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9065  [046] ....    24.307286: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9069  [029] ....    24.311957: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9072  [010] ....    24.315013: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9075  [002] ....    24.317803: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9078  [030] ....    24.320709: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9081  [011] ....    24.323806: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9085  [042] ....    24.329019: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9091  [049] ....    24.337911: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9100  [023] ....    24.392637: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9103  [058] ....    24.395753: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9106  [066] ....    24.398322: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9109  [023] ....    24.401226: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9112  [057] ....    24.404415: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9115  [045] ....    24.406961: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9125  [007] ....    24.460685: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9128  [021] ....    24.463883: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9284  [046] ....   340.883633: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802


Errors while loading ELF sections.

$dmesg | grep 'sed requested'

[   10.358608] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   10.358646] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   14.955315] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.063862] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.064445] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.334212] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.369408] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.436664] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.485034] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.692866] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.860316] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.864333] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.868912] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.906131] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.199315] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.212413] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.215787] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.223368] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.248050] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.250594] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.253236] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.255709] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.258191] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.260887] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.266149] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.269456] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.272336] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.275035] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.277572] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.280204] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.286818] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.289273] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.291999] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.294861] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.299508] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.302229] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.304801] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.307371] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.312062] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.315121] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.317913] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.320821] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.323901] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.329124] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.338009] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.392780] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.395842] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.398442] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.401325] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.404494] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.407072] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.460794] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.463986] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[  340.883717] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-23 15:58                             ` Anshuman Khandual
  0 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-23 15:58 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On 01/23/2018 06:15 PM, Michal Hocko wrote:
> On Tue 23-01-18 16:55:18, Anshuman Khandual wrote:
>> On 01/17/2018 01:37 PM, Michal Hocko wrote:
>>> On Thu 11-01-18 15:38:37, Anshuman Khandual wrote:
>>>> On 01/09/2018 09:43 PM, Michal Hocko wrote:
>>> [...]
>>>>> Did you manage to catch _who_ is requesting that anonymous mapping? Do
>>>>> you need a help with the debugging patch?
>>>>
>>>> Not yet, will get back on this.
>>>
>>> ping?
>>
>> Hey Michal,
>>
>> Missed this thread, my apologies. This problem is happening only with
>> certain binaries like 'sed', 'tmux', 'hostname', 'pkg-config' etc. As
>> you had mentioned before the map request collision is happening on
>> [10030000, 10040000] and [10030000, 10040000] ranges only which is
>> just a single PAGE_SIZE. You asked previously that who might have
>> requested the anon mapping which is already present in there ? Would
>> not that be the same process itself ? I am bit confused.
> 
> We are early in the ELF loading. If we are mapping over an existing
> mapping then we are effectivelly corrupting it. In other words exactly
> what this patch tries to prevent. I fail to see what would be a relevant
> anon mapping this early and why it would be colliding with elf
> segements.
> 
>> Would it be
>> helpful to trap all the mmap() requests from any of the binaries
>> and see where we might have created that anon mapping ?
> 
> Yeah, that is exactly what I was suggesting. Sorry for not being clear
> about that.
> 

Tried to instrument just for the 'sed' binary and dont see any where
it actually requests the anon VMA which got hit when loading the ELF
section which is strange. All these requested flags here already has
MAP_FIXED_NOREPLACE (0x100000). Wondering from where the anon VMA
actually came from.

cat /sys/kernel/debug/tracing/trace | grep '10030000 10040000'

             sed-7579  [008] ....    10.358521: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-7583  [060] ....    10.358640: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8520  [059] ....    14.955216: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8802  [040] ....    23.063756: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8804  [051] ....    23.064434: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8828  [051] ....    23.334103: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8836  [066] .n..    23.369308: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8859  [013] ....    23.436563: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8868  [020] ....    23.484949: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8916  [066] ....    23.692761: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8936  [065] ....    23.860220: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8941  [066] ....    23.864280: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8946  [006] ....    23.868742: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8952  [056] ....    23.906065: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8969  [044] ....    24.199167: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8975  [005] ....    24.212314: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8980  [046] ....    24.215694: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-8987  [028] ....    24.223261: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9001  [016] ....    24.247962: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9004  [048] ....    24.250521: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9007  [017] ....    24.253165: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9010  [005] ....    24.255651: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9013  [030] ....    24.258122: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9016  [004] ....    24.260814: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9020  [029] ....    24.266019: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9026  [003] .n..    24.269327: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9029  [053] ....    24.272223: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9032  [030] ....    24.274914: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9035  [068] ....    24.277492: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9038  [007] ....    24.280134: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9043  [065] ....    24.286741: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9046  [060] ....    24.289189: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9049  [018] ....    24.291915: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9052  [068] ....    24.294782: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9056  [044] ....    24.299412: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9059  [068] ....    24.302153: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9062  [055] ....    24.304719: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9065  [046] ....    24.307286: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9069  [029] ....    24.311957: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9072  [010] ....    24.315013: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9075  [002] ....    24.317803: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9078  [030] ....    24.320709: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9081  [011] ....    24.323806: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9085  [042] ....    24.329019: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9091  [049] ....    24.337911: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9100  [023] ....    24.392637: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9103  [058] ....    24.395753: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9106  [066] ....    24.398322: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9109  [023] ....    24.401226: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9112  [057] ....    24.404415: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9115  [045] ....    24.406961: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9125  [007] ....    24.460685: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9128  [021] ....    24.463883: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802
             sed-9284  [046] ....   340.883633: do_mmap: comm sed range [10030000 10040000] prot 3 flags 101802


Errors while loading ELF sections.

$dmesg | grep 'sed requested'

[   10.358608] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   10.358646] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   14.955315] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.063862] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.064445] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.334212] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.369408] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.436664] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.485034] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.692866] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.860316] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.864333] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.868912] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   23.906131] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.199315] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.212413] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.215787] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.223368] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.248050] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.250594] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.253236] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.255709] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.258191] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.260887] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.266149] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.269456] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.272336] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.275035] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.277572] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.280204] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.286818] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.289273] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.291999] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.294861] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.299508] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.302229] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.304801] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.307371] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.312062] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.315121] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.317913] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.320821] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.323901] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.329124] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.338009] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.392780] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.395842] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.398442] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.401325] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.404494] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.407072] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.460794] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[   24.463986] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon
[  340.883717] sed requested [10030000, 10040000] mapped [10030000, 10040000] 100073 anon

--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-23 15:58                             ` Anshuman Khandual
@ 2018-01-23 16:06                               ` Michal Hocko
  -1 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-23 16:06 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On Tue 23-01-18 21:28:28, Anshuman Khandual wrote:
> On 01/23/2018 06:15 PM, Michal Hocko wrote:
> > On Tue 23-01-18 16:55:18, Anshuman Khandual wrote:
> >> On 01/17/2018 01:37 PM, Michal Hocko wrote:
> >>> On Thu 11-01-18 15:38:37, Anshuman Khandual wrote:
> >>>> On 01/09/2018 09:43 PM, Michal Hocko wrote:
> >>> [...]
> >>>>> Did you manage to catch _who_ is requesting that anonymous mapping? Do
> >>>>> you need a help with the debugging patch?
> >>>>
> >>>> Not yet, will get back on this.
> >>>
> >>> ping?
> >>
> >> Hey Michal,
> >>
> >> Missed this thread, my apologies. This problem is happening only with
> >> certain binaries like 'sed', 'tmux', 'hostname', 'pkg-config' etc. As
> >> you had mentioned before the map request collision is happening on
> >> [10030000, 10040000] and [10030000, 10040000] ranges only which is
> >> just a single PAGE_SIZE. You asked previously that who might have
> >> requested the anon mapping which is already present in there ? Would
> >> not that be the same process itself ? I am bit confused.
> > 
> > We are early in the ELF loading. If we are mapping over an existing
> > mapping then we are effectivelly corrupting it. In other words exactly
> > what this patch tries to prevent. I fail to see what would be a relevant
> > anon mapping this early and why it would be colliding with elf
> > segements.
> > 
> >> Would it be
> >> helpful to trap all the mmap() requests from any of the binaries
> >> and see where we might have created that anon mapping ?
> > 
> > Yeah, that is exactly what I was suggesting. Sorry for not being clear
> > about that.
> > 
> 
> Tried to instrument just for the 'sed' binary and dont see any where
> it actually requests the anon VMA which got hit when loading the ELF
> section which is strange. All these requested flags here already has
> MAP_FIXED_NOREPLACE (0x100000). Wondering from where the anon VMA
> actually came from.

Could you try to dump backtrace?
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-23 16:06                               ` Michal Hocko
  0 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-23 16:06 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On Tue 23-01-18 21:28:28, Anshuman Khandual wrote:
> On 01/23/2018 06:15 PM, Michal Hocko wrote:
> > On Tue 23-01-18 16:55:18, Anshuman Khandual wrote:
> >> On 01/17/2018 01:37 PM, Michal Hocko wrote:
> >>> On Thu 11-01-18 15:38:37, Anshuman Khandual wrote:
> >>>> On 01/09/2018 09:43 PM, Michal Hocko wrote:
> >>> [...]
> >>>>> Did you manage to catch _who_ is requesting that anonymous mapping? Do
> >>>>> you need a help with the debugging patch?
> >>>>
> >>>> Not yet, will get back on this.
> >>>
> >>> ping?
> >>
> >> Hey Michal,
> >>
> >> Missed this thread, my apologies. This problem is happening only with
> >> certain binaries like 'sed', 'tmux', 'hostname', 'pkg-config' etc. As
> >> you had mentioned before the map request collision is happening on
> >> [10030000, 10040000] and [10030000, 10040000] ranges only which is
> >> just a single PAGE_SIZE. You asked previously that who might have
> >> requested the anon mapping which is already present in there ? Would
> >> not that be the same process itself ? I am bit confused.
> > 
> > We are early in the ELF loading. If we are mapping over an existing
> > mapping then we are effectivelly corrupting it. In other words exactly
> > what this patch tries to prevent. I fail to see what would be a relevant
> > anon mapping this early and why it would be colliding with elf
> > segements.
> > 
> >> Would it be
> >> helpful to trap all the mmap() requests from any of the binaries
> >> and see where we might have created that anon mapping ?
> > 
> > Yeah, that is exactly what I was suggesting. Sorry for not being clear
> > about that.
> > 
> 
> Tried to instrument just for the 'sed' binary and dont see any where
> it actually requests the anon VMA which got hit when loading the ELF
> section which is strange. All these requested flags here already has
> MAP_FIXED_NOREPLACE (0x100000). Wondering from where the anon VMA
> actually came from.

Could you try to dump backtrace?
-- 
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-23 16:06                               ` Michal Hocko
@ 2018-01-24  5:09                                 ` Anshuman Khandual
  -1 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-24  5:09 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On 01/23/2018 09:36 PM, Michal Hocko wrote:
> On Tue 23-01-18 21:28:28, Anshuman Khandual wrote:
>> On 01/23/2018 06:15 PM, Michal Hocko wrote:
>>> On Tue 23-01-18 16:55:18, Anshuman Khandual wrote:
>>>> On 01/17/2018 01:37 PM, Michal Hocko wrote:
>>>>> On Thu 11-01-18 15:38:37, Anshuman Khandual wrote:
>>>>>> On 01/09/2018 09:43 PM, Michal Hocko wrote:
>>>>> [...]
>>>>>>> Did you manage to catch _who_ is requesting that anonymous mapping? Do
>>>>>>> you need a help with the debugging patch?
>>>>>>
>>>>>> Not yet, will get back on this.
>>>>>
>>>>> ping?
>>>>
>>>> Hey Michal,
>>>>
>>>> Missed this thread, my apologies. This problem is happening only with
>>>> certain binaries like 'sed', 'tmux', 'hostname', 'pkg-config' etc. As
>>>> you had mentioned before the map request collision is happening on
>>>> [10030000, 10040000] and [10030000, 10040000] ranges only which is
>>>> just a single PAGE_SIZE. You asked previously that who might have
>>>> requested the anon mapping which is already present in there ? Would
>>>> not that be the same process itself ? I am bit confused.
>>>
>>> We are early in the ELF loading. If we are mapping over an existing
>>> mapping then we are effectivelly corrupting it. In other words exactly
>>> what this patch tries to prevent. I fail to see what would be a relevant
>>> anon mapping this early and why it would be colliding with elf
>>> segements.
>>>
>>>> Would it be
>>>> helpful to trap all the mmap() requests from any of the binaries
>>>> and see where we might have created that anon mapping ?
>>>
>>> Yeah, that is exactly what I was suggesting. Sorry for not being clear
>>> about that.
>>>
>>
>> Tried to instrument just for the 'sed' binary and dont see any where
>> it actually requests the anon VMA which got hit when loading the ELF
>> section which is strange. All these requested flags here already has
>> MAP_FIXED_NOREPLACE (0x100000). Wondering from where the anon VMA
>> actually came from.
> 
> Could you try to dump backtrace?

This is when it fails inside elf_map() function due to collision with
existing anon VMA mapping.

[c000201c9ad07880] [c000000000b0b4c0] dump_stack+0xb0/0xf0 (unreliable)
[c000201c9ad078c0] [c0000000003c4550] elf_map+0x2d0/0x310
[c000201c9ad07b60] [c0000000003c6258] load_elf_binary+0x6f8/0x158c
[c000201c9ad07c80] [c000000000352900] search_binary_handler+0xd0/0x270
[c000201c9ad07d10] [c000000000354838] do_execveat_common.isra.31+0x658/0x890
[c000201c9ad07df0] [c000000000354e80] SyS_execve+0x40/0x50
[c000201c9ad07e30] [c00000000000b220] system_call+0x58/0x6c

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-24  5:09                                 ` Anshuman Khandual
  0 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-24  5:09 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On 01/23/2018 09:36 PM, Michal Hocko wrote:
> On Tue 23-01-18 21:28:28, Anshuman Khandual wrote:
>> On 01/23/2018 06:15 PM, Michal Hocko wrote:
>>> On Tue 23-01-18 16:55:18, Anshuman Khandual wrote:
>>>> On 01/17/2018 01:37 PM, Michal Hocko wrote:
>>>>> On Thu 11-01-18 15:38:37, Anshuman Khandual wrote:
>>>>>> On 01/09/2018 09:43 PM, Michal Hocko wrote:
>>>>> [...]
>>>>>>> Did you manage to catch _who_ is requesting that anonymous mapping? Do
>>>>>>> you need a help with the debugging patch?
>>>>>>
>>>>>> Not yet, will get back on this.
>>>>>
>>>>> ping?
>>>>
>>>> Hey Michal,
>>>>
>>>> Missed this thread, my apologies. This problem is happening only with
>>>> certain binaries like 'sed', 'tmux', 'hostname', 'pkg-config' etc. As
>>>> you had mentioned before the map request collision is happening on
>>>> [10030000, 10040000] and [10030000, 10040000] ranges only which is
>>>> just a single PAGE_SIZE. You asked previously that who might have
>>>> requested the anon mapping which is already present in there ? Would
>>>> not that be the same process itself ? I am bit confused.
>>>
>>> We are early in the ELF loading. If we are mapping over an existing
>>> mapping then we are effectivelly corrupting it. In other words exactly
>>> what this patch tries to prevent. I fail to see what would be a relevant
>>> anon mapping this early and why it would be colliding with elf
>>> segements.
>>>
>>>> Would it be
>>>> helpful to trap all the mmap() requests from any of the binaries
>>>> and see where we might have created that anon mapping ?
>>>
>>> Yeah, that is exactly what I was suggesting. Sorry for not being clear
>>> about that.
>>>
>>
>> Tried to instrument just for the 'sed' binary and dont see any where
>> it actually requests the anon VMA which got hit when loading the ELF
>> section which is strange. All these requested flags here already has
>> MAP_FIXED_NOREPLACE (0x100000). Wondering from where the anon VMA
>> actually came from.
> 
> Could you try to dump backtrace?

This is when it fails inside elf_map() function due to collision with
existing anon VMA mapping.

[c000201c9ad07880] [c000000000b0b4c0] dump_stack+0xb0/0xf0 (unreliable)
[c000201c9ad078c0] [c0000000003c4550] elf_map+0x2d0/0x310
[c000201c9ad07b60] [c0000000003c6258] load_elf_binary+0x6f8/0x158c
[c000201c9ad07c80] [c000000000352900] search_binary_handler+0xd0/0x270
[c000201c9ad07d10] [c000000000354838] do_execveat_common.isra.31+0x658/0x890
[c000201c9ad07df0] [c000000000354e80] SyS_execve+0x40/0x50
[c000201c9ad07e30] [c00000000000b220] system_call+0x58/0x6c

--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-24  5:09                                 ` Anshuman Khandual
@ 2018-01-24  9:05                                   ` Michal Hocko
  -1 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-24  9:05 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On Wed 24-01-18 10:39:41, Anshuman Khandual wrote:
> On 01/23/2018 09:36 PM, Michal Hocko wrote:
> > On Tue 23-01-18 21:28:28, Anshuman Khandual wrote:
> >> On 01/23/2018 06:15 PM, Michal Hocko wrote:
> >>> On Tue 23-01-18 16:55:18, Anshuman Khandual wrote:
> >>>> On 01/17/2018 01:37 PM, Michal Hocko wrote:
> >>>>> On Thu 11-01-18 15:38:37, Anshuman Khandual wrote:
> >>>>>> On 01/09/2018 09:43 PM, Michal Hocko wrote:
> >>>>> [...]
> >>>>>>> Did you manage to catch _who_ is requesting that anonymous mapping? Do
> >>>>>>> you need a help with the debugging patch?
> >>>>>>
> >>>>>> Not yet, will get back on this.
> >>>>>
> >>>>> ping?
> >>>>
> >>>> Hey Michal,
> >>>>
> >>>> Missed this thread, my apologies. This problem is happening only with
> >>>> certain binaries like 'sed', 'tmux', 'hostname', 'pkg-config' etc. As
> >>>> you had mentioned before the map request collision is happening on
> >>>> [10030000, 10040000] and [10030000, 10040000] ranges only which is
> >>>> just a single PAGE_SIZE. You asked previously that who might have
> >>>> requested the anon mapping which is already present in there ? Would
> >>>> not that be the same process itself ? I am bit confused.
> >>>
> >>> We are early in the ELF loading. If we are mapping over an existing
> >>> mapping then we are effectivelly corrupting it. In other words exactly
> >>> what this patch tries to prevent. I fail to see what would be a relevant
> >>> anon mapping this early and why it would be colliding with elf
> >>> segements.
> >>>
> >>>> Would it be
> >>>> helpful to trap all the mmap() requests from any of the binaries
> >>>> and see where we might have created that anon mapping ?
> >>>
> >>> Yeah, that is exactly what I was suggesting. Sorry for not being clear
> >>> about that.
> >>>
> >>
> >> Tried to instrument just for the 'sed' binary and dont see any where
> >> it actually requests the anon VMA which got hit when loading the ELF
> >> section which is strange. All these requested flags here already has
> >> MAP_FIXED_NOREPLACE (0x100000). Wondering from where the anon VMA
> >> actually came from.
> > 
> > Could you try to dump backtrace?
> 
> This is when it fails inside elf_map() function due to collision with
> existing anon VMA mapping.

This is not the interesting one. This is the ELF loader. And we know it
fails. We are really interested in the one _who_ installs the original
VMA. Because nothing should be really there.

It would be also very helpful to translate the backtrace with faddr2line
to get line numbers.

> [c000201c9ad07880] [c000000000b0b4c0] dump_stack+0xb0/0xf0 (unreliable)
> [c000201c9ad078c0] [c0000000003c4550] elf_map+0x2d0/0x310
> [c000201c9ad07b60] [c0000000003c6258] load_elf_binary+0x6f8/0x158c
> [c000201c9ad07c80] [c000000000352900] search_binary_handler+0xd0/0x270
> [c000201c9ad07d10] [c000000000354838] do_execveat_common.isra.31+0x658/0x890
> [c000201c9ad07df0] [c000000000354e80] SyS_execve+0x40/0x50
> [c000201c9ad07e30] [c00000000000b220] system_call+0x58/0x6c

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-24  9:05                                   ` Michal Hocko
  0 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-24  9:05 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On Wed 24-01-18 10:39:41, Anshuman Khandual wrote:
> On 01/23/2018 09:36 PM, Michal Hocko wrote:
> > On Tue 23-01-18 21:28:28, Anshuman Khandual wrote:
> >> On 01/23/2018 06:15 PM, Michal Hocko wrote:
> >>> On Tue 23-01-18 16:55:18, Anshuman Khandual wrote:
> >>>> On 01/17/2018 01:37 PM, Michal Hocko wrote:
> >>>>> On Thu 11-01-18 15:38:37, Anshuman Khandual wrote:
> >>>>>> On 01/09/2018 09:43 PM, Michal Hocko wrote:
> >>>>> [...]
> >>>>>>> Did you manage to catch _who_ is requesting that anonymous mapping? Do
> >>>>>>> you need a help with the debugging patch?
> >>>>>>
> >>>>>> Not yet, will get back on this.
> >>>>>
> >>>>> ping?
> >>>>
> >>>> Hey Michal,
> >>>>
> >>>> Missed this thread, my apologies. This problem is happening only with
> >>>> certain binaries like 'sed', 'tmux', 'hostname', 'pkg-config' etc. As
> >>>> you had mentioned before the map request collision is happening on
> >>>> [10030000, 10040000] and [10030000, 10040000] ranges only which is
> >>>> just a single PAGE_SIZE. You asked previously that who might have
> >>>> requested the anon mapping which is already present in there ? Would
> >>>> not that be the same process itself ? I am bit confused.
> >>>
> >>> We are early in the ELF loading. If we are mapping over an existing
> >>> mapping then we are effectivelly corrupting it. In other words exactly
> >>> what this patch tries to prevent. I fail to see what would be a relevant
> >>> anon mapping this early and why it would be colliding with elf
> >>> segements.
> >>>
> >>>> Would it be
> >>>> helpful to trap all the mmap() requests from any of the binaries
> >>>> and see where we might have created that anon mapping ?
> >>>
> >>> Yeah, that is exactly what I was suggesting. Sorry for not being clear
> >>> about that.
> >>>
> >>
> >> Tried to instrument just for the 'sed' binary and dont see any where
> >> it actually requests the anon VMA which got hit when loading the ELF
> >> section which is strange. All these requested flags here already has
> >> MAP_FIXED_NOREPLACE (0x100000). Wondering from where the anon VMA
> >> actually came from.
> > 
> > Could you try to dump backtrace?
> 
> This is when it fails inside elf_map() function due to collision with
> existing anon VMA mapping.

This is not the interesting one. This is the ELF loader. And we know it
fails. We are really interested in the one _who_ installs the original
VMA. Because nothing should be really there.

It would be also very helpful to translate the backtrace with faddr2line
to get line numbers.

> [c000201c9ad07880] [c000000000b0b4c0] dump_stack+0xb0/0xf0 (unreliable)
> [c000201c9ad078c0] [c0000000003c4550] elf_map+0x2d0/0x310
> [c000201c9ad07b60] [c0000000003c6258] load_elf_binary+0x6f8/0x158c
> [c000201c9ad07c80] [c000000000352900] search_binary_handler+0xd0/0x270
> [c000201c9ad07d10] [c000000000354838] do_execveat_common.isra.31+0x658/0x890
> [c000201c9ad07df0] [c000000000354e80] SyS_execve+0x40/0x50
> [c000201c9ad07e30] [c00000000000b220] system_call+0x58/0x6c

-- 
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-24  9:05                                   ` Michal Hocko
@ 2018-01-26 12:34                                     ` Anshuman Khandual
  -1 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-26 12:34 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On 01/24/2018 02:35 PM, Michal Hocko wrote:
> On Wed 24-01-18 10:39:41, Anshuman Khandual wrote:
>> On 01/23/2018 09:36 PM, Michal Hocko wrote:
>>> On Tue 23-01-18 21:28:28, Anshuman Khandual wrote:
>>>> On 01/23/2018 06:15 PM, Michal Hocko wrote:
>>>>> On Tue 23-01-18 16:55:18, Anshuman Khandual wrote:
>>>>>> On 01/17/2018 01:37 PM, Michal Hocko wrote:
>>>>>>> On Thu 11-01-18 15:38:37, Anshuman Khandual wrote:
>>>>>>>> On 01/09/2018 09:43 PM, Michal Hocko wrote:
>>>>>>> [...]
>>>>>>>>> Did you manage to catch _who_ is requesting that anonymous mapping? Do
>>>>>>>>> you need a help with the debugging patch?
>>>>>>>> Not yet, will get back on this.
>>>>>>> ping?
>>>>>> Hey Michal,
>>>>>>
>>>>>> Missed this thread, my apologies. This problem is happening only with
>>>>>> certain binaries like 'sed', 'tmux', 'hostname', 'pkg-config' etc. As
>>>>>> you had mentioned before the map request collision is happening on
>>>>>> [10030000, 10040000] and [10030000, 10040000] ranges only which is
>>>>>> just a single PAGE_SIZE. You asked previously that who might have
>>>>>> requested the anon mapping which is already present in there ? Would
>>>>>> not that be the same process itself ? I am bit confused.
>>>>> We are early in the ELF loading. If we are mapping over an existing
>>>>> mapping then we are effectivelly corrupting it. In other words exactly
>>>>> what this patch tries to prevent. I fail to see what would be a relevant
>>>>> anon mapping this early and why it would be colliding with elf
>>>>> segements.
>>>>>
>>>>>> Would it be
>>>>>> helpful to trap all the mmap() requests from any of the binaries
>>>>>> and see where we might have created that anon mapping ?
>>>>> Yeah, that is exactly what I was suggesting. Sorry for not being clear
>>>>> about that.
>>>>>
>>>> Tried to instrument just for the 'sed' binary and dont see any where
>>>> it actually requests the anon VMA which got hit when loading the ELF
>>>> section which is strange. All these requested flags here already has
>>>> MAP_FIXED_NOREPLACE (0x100000). Wondering from where the anon VMA
>>>> actually came from.
>>> Could you try to dump backtrace?
>> This is when it fails inside elf_map() function due to collision with
>> existing anon VMA mapping.
> This is not the interesting one. This is the ELF loader. And we know it
> fails. We are really interested in the one _who_ installs the original
> VMA. Because nothing should be really there.
> 

I tried to instrument mmap_region() for a single instance of 'sed'
binary and traced all it's VMA creation. But there is no trace when
that 'anon' VMA got created which suddenly shows up during subsequent
elf_map() call eventually failing it. Please note that the following
VMA was never created through call into map_region() in the process
which is strange.

=================================================================
[    9.076867] Details for VMA[3] c000001fce42b7c0
[    9.076925] vma c000001fce42b7c0 start 0000000010030000 end 0000000010040000
next c000001fce42b580 prev c000001fce42b880 mm c000001fce40fa00
prot 8000000000000104 anon_vma           (null) vm_ops           (null)
pgoff 1003 file           (null) private_data           (null)
flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
=================================================================

VMA creation for 'sed' binary
=============================
[    9.071902] XXX: mm c000001fce40fa00 registered

[    9.071971] Total VMAs 2 on MM c000001fce40fa00
----
[    9.072010] Details for VMA[1] c000001fce42bdc0
[    9.072064] vma c000001fce42bdc0 start 0000000010000000 end 0000000010020000
next c000001fce42b580 prev           (null) mm c000001fce40fa00
prot 8000000000000105 anon_vma           (null) vm_ops c008000011ddca18
pgoff 0 file c000001fe2969a00 private_data           (null)
flags: 0x875(read|exec|mayread|maywrite|mayexec|denywrite)
----
[    9.072402] Details for VMA[2] c000001fce42b580
[    9.072469] vma c000001fce42b580 start 00007fffcafe0000 end 00007fffcb010000
next           (null) prev c000001fce42bdc0 mm c000001fce40fa00
prot 8000000000000104 anon_vma c000001fce4456f0 vm_ops           (null)
pgoff 1fffffffd file           (null) private_data           (null)
flags: 0x100173(read|write|mayread|maywrite|mayexec|growsdown|account)

[    9.072839] CPU: 48 PID: 7544 Comm: sed Not tainted 4.14.0-dirty #154
[    9.072928] Call Trace:
[    9.072952] [c000001fbef37840] [c000000000b17a00] dump_stack+0xb0/0xf0 (unreliable)
[    9.073021] [c000001fbef37880] [c0000000002dbc48] mmap_region+0x718/0x720
[    9.073097] [c000001fbef37970] [c0000000002dc034] do_mmap+0x3e4/0x480
[    9.073179] [c000001fbef379f0] [c0000000002a96c8] vm_mmap_pgoff+0xe8/0x120
[    9.073268] [c000001fbef37ac0] [c0000000003cf378] elf_map+0x98/0x270
[    9.073326] [c000001fbef37b60] [c0000000003d1258] load_elf_binary+0x6f8/0x158c
[    9.073416] [c000001fbef37c80] [c00000000035d320] search_binary_handler+0xd0/0x270
[    9.073510] [c000001fbef37d10] [c00000000035f278] do_execveat_common.isra.31+0x658/0x890
[    9.073599] [c000001fbef37df0] [c00000000035f8c0] SyS_execve+0x40/0x50
[    9.073673] [c000001fbef37e30] [c00000000000b220] system_call+0x58/0x6c


[    9.073749] Total VMAs 3 on MM c000001fce40fa00
----
[    9.073795] Details for VMA[1] c000001fce42bdc0
[    9.073847] vma c000001fce42bdc0 start 0000000010000000 end 0000000010020000
next c000001fce42b880 prev           (null) mm c000001fce40fa00
prot 8000000000000105 anon_vma           (null) vm_ops c008000011ddca18
pgoff 0 file c000001fe2969a00 private_data           (null)
flags: 0x875(read|exec|mayread|maywrite|mayexec|denywrite)
----
[    9.074170] Details for VMA[2] c000001fce42b880
[    9.074236] vma c000001fce42b880 start 0000000010020000 end 0000000010030000
next c000001fce42b580 prev c000001fce42bdc0 mm c000001fce40fa00
prot 8000000000000104 anon_vma           (null) vm_ops c008000011ddca18
pgoff 1 file c000001fe2969a00 private_data           (null)
flags: 0x100873(read|write|mayread|maywrite|mayexec|denywrite|account)
----
[    9.074612] Details for VMA[3] c000001fce42b580
[    9.074661] vma c000001fce42b580 start 00007fffcafe0000 end 00007fffcb010000
next           (null) prev c000001fce42b880 mm c000001fce40fa00
prot 8000000000000104 anon_vma c000001fce4456f0 vm_ops           (null)
pgoff 1fffffffd file           (null) private_data           (null)
flags: 0x100173(read|write|mayread|maywrite|mayexec|growsdown|account)

[    9.075038] CPU: 48 PID: 7544 Comm: sed Not tainted 4.14.0-dirty #154
[    9.075104] Call Trace:
[    9.075124] [c000001fbef37840] [c000000000b17a00] dump_stack+0xb0/0xf0 (unreliable)
[    9.075212] [c000001fbef37880] [c0000000002db824] mmap_region+0x2f4/0x720
[    9.075288] [c000001fbef37970] [c0000000002dc034] do_mmap+0x3e4/0x480
[    9.075358] [c000001fbef379f0] [c0000000002a96c8] vm_mmap_pgoff+0xe8/0x120
[    9.075432] [c000001fbef37ac0] [c0000000003cf378] elf_map+0x98/0x270
[    9.075490] [c000001fbef37b60] [c0000000003d1258] load_elf_binary+0x6f8/0x158c
[    9.075591] [c000001fbef37c80] [c00000000035d320] search_binary_handler+0xd0/0x270
[    9.075675] [c000001fbef37d10] [c00000000035f278] do_execveat_common.isra.31+0x658/0x890
[    9.075765] [c000001fbef37df0] [c00000000035f8c0] SyS_execve+0x40/0x50
[    9.075834] [c000001fbef37e30] [c00000000000b220] system_call+0x58/0x6c

When it fails
===============
[    9.075910] 7544 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already

[    9.076010] Total VMAs 4 on MM c000001fce40fa00
----
[    9.076055] Details for VMA[1] c000001fce42bdc0
[    9.076103] vma c000001fce42bdc0 start 0000000010000000 end 0000000010020000
next c000001fce42b880 prev           (null) mm c000001fce40fa00
prot 8000000000000105 anon_vma           (null) vm_ops c008000011ddca18
pgoff 0 file c000001fe2969a00 private_data           (null)
flags: 0x875(read|exec|mayread|maywrite|mayexec|denywrite)
----
[    9.076461] Details for VMA[2] c000001fce42b880
[    9.076509] vma c000001fce42b880 start 0000000010020000 end 0000000010030000
next c000001fce42b7c0 prev c000001fce42bdc0 mm c000001fce40fa00
prot 8000000000000104 anon_vma           (null) vm_ops c008000011ddca18
pgoff 1 file c000001fe2969a00 private_data           (null)
flags: 0x100873(read|write|mayread|maywrite|mayexec|denywrite|account)
----
[    9.076867] Details for VMA[3] c000001fce42b7c0
[    9.076925] vma c000001fce42b7c0 start 0000000010030000 end 0000000010040000
next c000001fce42b580 prev c000001fce42b880 mm c000001fce40fa00
prot 8000000000000104 anon_vma           (null) vm_ops           (null)
pgoff 1003 file           (null) private_data           (null)
flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
-----
[    9.077285] Details for VMA[4] c000001fce42b580
[    9.077335] vma c000001fce42b580 start 00007fffcafe0000 end 00007fffcb010000
next           (null) prev c000001fce42b7c0 mm c000001fce40fa00
prot 8000000000000104 anon_vma c000001fce4456f0 vm_ops           (null)
pgoff 1fffffffd file           (null) private_data           (null)
flags: 0x100173(read|write|mayread|maywrite|mayexec|growsdown|account)

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-26 12:34                                     ` Anshuman Khandual
  0 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-26 12:34 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On 01/24/2018 02:35 PM, Michal Hocko wrote:
> On Wed 24-01-18 10:39:41, Anshuman Khandual wrote:
>> On 01/23/2018 09:36 PM, Michal Hocko wrote:
>>> On Tue 23-01-18 21:28:28, Anshuman Khandual wrote:
>>>> On 01/23/2018 06:15 PM, Michal Hocko wrote:
>>>>> On Tue 23-01-18 16:55:18, Anshuman Khandual wrote:
>>>>>> On 01/17/2018 01:37 PM, Michal Hocko wrote:
>>>>>>> On Thu 11-01-18 15:38:37, Anshuman Khandual wrote:
>>>>>>>> On 01/09/2018 09:43 PM, Michal Hocko wrote:
>>>>>>> [...]
>>>>>>>>> Did you manage to catch _who_ is requesting that anonymous mapping? Do
>>>>>>>>> you need a help with the debugging patch?
>>>>>>>> Not yet, will get back on this.
>>>>>>> ping?
>>>>>> Hey Michal,
>>>>>>
>>>>>> Missed this thread, my apologies. This problem is happening only with
>>>>>> certain binaries like 'sed', 'tmux', 'hostname', 'pkg-config' etc. As
>>>>>> you had mentioned before the map request collision is happening on
>>>>>> [10030000, 10040000] and [10030000, 10040000] ranges only which is
>>>>>> just a single PAGE_SIZE. You asked previously that who might have
>>>>>> requested the anon mapping which is already present in there ? Would
>>>>>> not that be the same process itself ? I am bit confused.
>>>>> We are early in the ELF loading. If we are mapping over an existing
>>>>> mapping then we are effectivelly corrupting it. In other words exactly
>>>>> what this patch tries to prevent. I fail to see what would be a relevant
>>>>> anon mapping this early and why it would be colliding with elf
>>>>> segements.
>>>>>
>>>>>> Would it be
>>>>>> helpful to trap all the mmap() requests from any of the binaries
>>>>>> and see where we might have created that anon mapping ?
>>>>> Yeah, that is exactly what I was suggesting. Sorry for not being clear
>>>>> about that.
>>>>>
>>>> Tried to instrument just for the 'sed' binary and dont see any where
>>>> it actually requests the anon VMA which got hit when loading the ELF
>>>> section which is strange. All these requested flags here already has
>>>> MAP_FIXED_NOREPLACE (0x100000). Wondering from where the anon VMA
>>>> actually came from.
>>> Could you try to dump backtrace?
>> This is when it fails inside elf_map() function due to collision with
>> existing anon VMA mapping.
> This is not the interesting one. This is the ELF loader. And we know it
> fails. We are really interested in the one _who_ installs the original
> VMA. Because nothing should be really there.
> 

I tried to instrument mmap_region() for a single instance of 'sed'
binary and traced all it's VMA creation. But there is no trace when
that 'anon' VMA got created which suddenly shows up during subsequent
elf_map() call eventually failing it. Please note that the following
VMA was never created through call into map_region() in the process
which is strange.

=================================================================
[    9.076867] Details for VMA[3] c000001fce42b7c0
[    9.076925] vma c000001fce42b7c0 start 0000000010030000 end 0000000010040000
next c000001fce42b580 prev c000001fce42b880 mm c000001fce40fa00
prot 8000000000000104 anon_vma           (null) vm_ops           (null)
pgoff 1003 file           (null) private_data           (null)
flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
=================================================================

VMA creation for 'sed' binary
=============================
[    9.071902] XXX: mm c000001fce40fa00 registered

[    9.071971] Total VMAs 2 on MM c000001fce40fa00
----
[    9.072010] Details for VMA[1] c000001fce42bdc0
[    9.072064] vma c000001fce42bdc0 start 0000000010000000 end 0000000010020000
next c000001fce42b580 prev           (null) mm c000001fce40fa00
prot 8000000000000105 anon_vma           (null) vm_ops c008000011ddca18
pgoff 0 file c000001fe2969a00 private_data           (null)
flags: 0x875(read|exec|mayread|maywrite|mayexec|denywrite)
----
[    9.072402] Details for VMA[2] c000001fce42b580
[    9.072469] vma c000001fce42b580 start 00007fffcafe0000 end 00007fffcb010000
next           (null) prev c000001fce42bdc0 mm c000001fce40fa00
prot 8000000000000104 anon_vma c000001fce4456f0 vm_ops           (null)
pgoff 1fffffffd file           (null) private_data           (null)
flags: 0x100173(read|write|mayread|maywrite|mayexec|growsdown|account)

[    9.072839] CPU: 48 PID: 7544 Comm: sed Not tainted 4.14.0-dirty #154
[    9.072928] Call Trace:
[    9.072952] [c000001fbef37840] [c000000000b17a00] dump_stack+0xb0/0xf0 (unreliable)
[    9.073021] [c000001fbef37880] [c0000000002dbc48] mmap_region+0x718/0x720
[    9.073097] [c000001fbef37970] [c0000000002dc034] do_mmap+0x3e4/0x480
[    9.073179] [c000001fbef379f0] [c0000000002a96c8] vm_mmap_pgoff+0xe8/0x120
[    9.073268] [c000001fbef37ac0] [c0000000003cf378] elf_map+0x98/0x270
[    9.073326] [c000001fbef37b60] [c0000000003d1258] load_elf_binary+0x6f8/0x158c
[    9.073416] [c000001fbef37c80] [c00000000035d320] search_binary_handler+0xd0/0x270
[    9.073510] [c000001fbef37d10] [c00000000035f278] do_execveat_common.isra.31+0x658/0x890
[    9.073599] [c000001fbef37df0] [c00000000035f8c0] SyS_execve+0x40/0x50
[    9.073673] [c000001fbef37e30] [c00000000000b220] system_call+0x58/0x6c


[    9.073749] Total VMAs 3 on MM c000001fce40fa00
----
[    9.073795] Details for VMA[1] c000001fce42bdc0
[    9.073847] vma c000001fce42bdc0 start 0000000010000000 end 0000000010020000
next c000001fce42b880 prev           (null) mm c000001fce40fa00
prot 8000000000000105 anon_vma           (null) vm_ops c008000011ddca18
pgoff 0 file c000001fe2969a00 private_data           (null)
flags: 0x875(read|exec|mayread|maywrite|mayexec|denywrite)
----
[    9.074170] Details for VMA[2] c000001fce42b880
[    9.074236] vma c000001fce42b880 start 0000000010020000 end 0000000010030000
next c000001fce42b580 prev c000001fce42bdc0 mm c000001fce40fa00
prot 8000000000000104 anon_vma           (null) vm_ops c008000011ddca18
pgoff 1 file c000001fe2969a00 private_data           (null)
flags: 0x100873(read|write|mayread|maywrite|mayexec|denywrite|account)
----
[    9.074612] Details for VMA[3] c000001fce42b580
[    9.074661] vma c000001fce42b580 start 00007fffcafe0000 end 00007fffcb010000
next           (null) prev c000001fce42b880 mm c000001fce40fa00
prot 8000000000000104 anon_vma c000001fce4456f0 vm_ops           (null)
pgoff 1fffffffd file           (null) private_data           (null)
flags: 0x100173(read|write|mayread|maywrite|mayexec|growsdown|account)

[    9.075038] CPU: 48 PID: 7544 Comm: sed Not tainted 4.14.0-dirty #154
[    9.075104] Call Trace:
[    9.075124] [c000001fbef37840] [c000000000b17a00] dump_stack+0xb0/0xf0 (unreliable)
[    9.075212] [c000001fbef37880] [c0000000002db824] mmap_region+0x2f4/0x720
[    9.075288] [c000001fbef37970] [c0000000002dc034] do_mmap+0x3e4/0x480
[    9.075358] [c000001fbef379f0] [c0000000002a96c8] vm_mmap_pgoff+0xe8/0x120
[    9.075432] [c000001fbef37ac0] [c0000000003cf378] elf_map+0x98/0x270
[    9.075490] [c000001fbef37b60] [c0000000003d1258] load_elf_binary+0x6f8/0x158c
[    9.075591] [c000001fbef37c80] [c00000000035d320] search_binary_handler+0xd0/0x270
[    9.075675] [c000001fbef37d10] [c00000000035f278] do_execveat_common.isra.31+0x658/0x890
[    9.075765] [c000001fbef37df0] [c00000000035f8c0] SyS_execve+0x40/0x50
[    9.075834] [c000001fbef37e30] [c00000000000b220] system_call+0x58/0x6c

When it fails
===============
[    9.075910] 7544 (sed): Uhuuh, elf segment at 0000000010030000 requested but the memory is mapped already

[    9.076010] Total VMAs 4 on MM c000001fce40fa00
----
[    9.076055] Details for VMA[1] c000001fce42bdc0
[    9.076103] vma c000001fce42bdc0 start 0000000010000000 end 0000000010020000
next c000001fce42b880 prev           (null) mm c000001fce40fa00
prot 8000000000000105 anon_vma           (null) vm_ops c008000011ddca18
pgoff 0 file c000001fe2969a00 private_data           (null)
flags: 0x875(read|exec|mayread|maywrite|mayexec|denywrite)
----
[    9.076461] Details for VMA[2] c000001fce42b880
[    9.076509] vma c000001fce42b880 start 0000000010020000 end 0000000010030000
next c000001fce42b7c0 prev c000001fce42bdc0 mm c000001fce40fa00
prot 8000000000000104 anon_vma           (null) vm_ops c008000011ddca18
pgoff 1 file c000001fe2969a00 private_data           (null)
flags: 0x100873(read|write|mayread|maywrite|mayexec|denywrite|account)
----
[    9.076867] Details for VMA[3] c000001fce42b7c0
[    9.076925] vma c000001fce42b7c0 start 0000000010030000 end 0000000010040000
next c000001fce42b580 prev c000001fce42b880 mm c000001fce40fa00
prot 8000000000000104 anon_vma           (null) vm_ops           (null)
pgoff 1003 file           (null) private_data           (null)
flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
-----
[    9.077285] Details for VMA[4] c000001fce42b580
[    9.077335] vma c000001fce42b580 start 00007fffcafe0000 end 00007fffcb010000
next           (null) prev c000001fce42b7c0 mm c000001fce40fa00
prot 8000000000000104 anon_vma c000001fce4456f0 vm_ops           (null)
pgoff 1fffffffd file           (null) private_data           (null)
flags: 0x100173(read|write|mayread|maywrite|mayexec|growsdown|account)

--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-26 12:34                                     ` Anshuman Khandual
@ 2018-01-26 14:04                                       ` Michal Hocko
  -1 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-26 14:04 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On Fri 26-01-18 18:04:27, Anshuman Khandual wrote:
[...]
> I tried to instrument mmap_region() for a single instance of 'sed'
> binary and traced all it's VMA creation. But there is no trace when
> that 'anon' VMA got created which suddenly shows up during subsequent
> elf_map() call eventually failing it. Please note that the following
> VMA was never created through call into map_region() in the process
> which is strange.

Could you share your debugging patch?

> =================================================================
> [    9.076867] Details for VMA[3] c000001fce42b7c0
> [    9.076925] vma c000001fce42b7c0 start 0000000010030000 end 0000000010040000
> next c000001fce42b580 prev c000001fce42b880 mm c000001fce40fa00
> prot 8000000000000104 anon_vma           (null) vm_ops           (null)
> pgoff 1003 file           (null) private_data           (null)
> flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
> =================================================================

Isn't this vdso or some other special mapping? It is not really an
anonymous vma. Please hook into __install_special_mapping

> VMA creation for 'sed' binary
> =============================
> [    9.071902] XXX: mm c000001fce40fa00 registered
> 
> [    9.071971] Total VMAs 2 on MM c000001fce40fa00
> ----
> [    9.072010] Details for VMA[1] c000001fce42bdc0
> [    9.072064] vma c000001fce42bdc0 start 0000000010000000 end 0000000010020000
> next c000001fce42b580 prev           (null) mm c000001fce40fa00
> prot 8000000000000105 anon_vma           (null) vm_ops c008000011ddca18
> pgoff 0 file c000001fe2969a00 private_data           (null)
> flags: 0x875(read|exec|mayread|maywrite|mayexec|denywrite)

This one doesn't have any stack trace either... Yet it is a file
mapping obviously. Special mappings shouldn't have any file associated.
Strange...
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-26 14:04                                       ` Michal Hocko
  0 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-26 14:04 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On Fri 26-01-18 18:04:27, Anshuman Khandual wrote:
[...]
> I tried to instrument mmap_region() for a single instance of 'sed'
> binary and traced all it's VMA creation. But there is no trace when
> that 'anon' VMA got created which suddenly shows up during subsequent
> elf_map() call eventually failing it. Please note that the following
> VMA was never created through call into map_region() in the process
> which is strange.

Could you share your debugging patch?

> =================================================================
> [    9.076867] Details for VMA[3] c000001fce42b7c0
> [    9.076925] vma c000001fce42b7c0 start 0000000010030000 end 0000000010040000
> next c000001fce42b580 prev c000001fce42b880 mm c000001fce40fa00
> prot 8000000000000104 anon_vma           (null) vm_ops           (null)
> pgoff 1003 file           (null) private_data           (null)
> flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
> =================================================================

Isn't this vdso or some other special mapping? It is not really an
anonymous vma. Please hook into __install_special_mapping

> VMA creation for 'sed' binary
> =============================
> [    9.071902] XXX: mm c000001fce40fa00 registered
> 
> [    9.071971] Total VMAs 2 on MM c000001fce40fa00
> ----
> [    9.072010] Details for VMA[1] c000001fce42bdc0
> [    9.072064] vma c000001fce42bdc0 start 0000000010000000 end 0000000010020000
> next c000001fce42b580 prev           (null) mm c000001fce40fa00
> prot 8000000000000105 anon_vma           (null) vm_ops c008000011ddca18
> pgoff 0 file c000001fe2969a00 private_data           (null)
> flags: 0x875(read|exec|mayread|maywrite|mayexec|denywrite)

This one doesn't have any stack trace either... Yet it is a file
mapping obviously. Special mappings shouldn't have any file associated.
Strange...
-- 
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-26 14:04                                       ` Michal Hocko
@ 2018-01-29  2:47                                         ` Anshuman Khandual
  -1 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-29  2:47 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On 01/26/2018 07:34 PM, Michal Hocko wrote:
> On Fri 26-01-18 18:04:27, Anshuman Khandual wrote:
> [...]
>> I tried to instrument mmap_region() for a single instance of 'sed'
>> binary and traced all it's VMA creation. But there is no trace when
>> that 'anon' VMA got created which suddenly shows up during subsequent
>> elf_map() call eventually failing it. Please note that the following
>> VMA was never created through call into map_region() in the process
>> which is strange.
> 
> Could you share your debugging patch?

Please find the debug patch at the end.

> 
>> =================================================================
>> [    9.076867] Details for VMA[3] c000001fce42b7c0
>> [    9.076925] vma c000001fce42b7c0 start 0000000010030000 end 0000000010040000
>> next c000001fce42b580 prev c000001fce42b880 mm c000001fce40fa00
>> prot 8000000000000104 anon_vma           (null) vm_ops           (null)
>> pgoff 1003 file           (null) private_data           (null)
>> flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
>> =================================================================
> 
> Isn't this vdso or some other special mapping? It is not really an
> anonymous vma. Please hook into __install_special_mapping

Yeah, will do. Its not an anon mapping as it does not have a anon_vma
structure ?

> 
>> VMA creation for 'sed' binary
>> =============================
>> [    9.071902] XXX: mm c000001fce40fa00 registered
>>
>> [    9.071971] Total VMAs 2 on MM c000001fce40fa00
>> ----
>> [    9.072010] Details for VMA[1] c000001fce42bdc0
>> [    9.072064] vma c000001fce42bdc0 start 0000000010000000 end 0000000010020000
>> next c000001fce42b580 prev           (null) mm c000001fce40fa00
>> prot 8000000000000105 anon_vma           (null) vm_ops c008000011ddca18
>> pgoff 0 file c000001fe2969a00 private_data           (null)
>> flags: 0x875(read|exec|mayread|maywrite|mayexec|denywrite)
> 
> This one doesn't have any stack trace either... Yet it is a file
> mapping obviously. Special mappings shouldn't have any file associated.
> Strange...

IIUC, the first VMA (which seems to be an anon VMA) did not have any
stack trace and not sure how it got created.

[    9.077335] vma c000001fce42b580 start 00007fffcafe0000 end 00007fffcb010000
next           (null) prev c000001fce42b7c0 mm c000001fce40fa00
prot 8000000000000104 anon_vma c000001fce4456f0 vm_ops           (null)
pgoff 1fffffffd file           (null) private_data           (null)
flags: 0x100173(read|write|mayread|maywrite|mayexec|growsdown|account)

the subsequent ones, this

[    9.072010] Details for VMA[1] c000001fce42bdc0
[    9.072064] vma c000001fce42bdc0 start 0000000010000000 end 0000000010020000
next c000001fce42b580 prev           (null) mm c000001fce40fa00
prot 8000000000000105 anon_vma           (null) vm_ops c008000011ddca18
pgoff 0 file c000001fe2969a00 private_data           (null)
flags: 0x875(read|exec|mayread|maywrite|mayexec|denywrite)

and this (both are file mapping for sure and getting loaded from elf)

[    9.074170] Details for VMA[2] c000001fce42b880
[    9.074236] vma c000001fce42b880 start 0000000010020000 end 0000000010030000
next c000001fce42b580 prev c000001fce42bdc0 mm c000001fce40fa00
prot 8000000000000104 anon_vma           (null) vm_ops c008000011ddca18
pgoff 1 file c000001fe2969a00 private_data           (null)
flags: 0x100873(read|write|mayread|maywrite|mayexec|denywrite|account)

have similar stack traces

[    9.072839] CPU: 48 PID: 7544 Comm: sed Not tainted 4.14.0-dirty #154
[    9.072928] Call Trace:
[    9.072952] [c000001fbef37840] [c000000000b17a00] dump_stack+0xb0/0xf0 (unreliable)
[    9.073021] [c000001fbef37880] [c0000000002dbc48] mmap_region+0x718/0x720
[    9.073097] [c000001fbef37970] [c0000000002dc034] do_mmap+0x3e4/0x480
[    9.073179] [c000001fbef379f0] [c0000000002a96c8] vm_mmap_pgoff+0xe8/0x120
[    9.073268] [c000001fbef37ac0] [c0000000003cf378] elf_map+0x98/0x270
[    9.073326] [c000001fbef37b60] [c0000000003d1258] load_elf_binary+0x6f8/0x158c
[    9.073416] [c000001fbef37c80] [c00000000035d320] search_binary_handler+0xd0/0x270
[    9.073510] [c000001fbef37d10] [c00000000035f278] do_execveat_common.isra.31+0x658/0x890
[    9.073599] [c000001fbef37df0] [c00000000035f8c0] SyS_execve+0x40/0x50
[    9.073673] [c000001fbef37e30] [c00000000000b220] system_call+0x58/0x6c

and then again this one (which causes the collision subsequently) is neither
a anon VMA nor a file VMA and does not have a stack trace either.

[    9.076867] Details for VMA[3] c000001fce42b7c0
[    9.076925] vma c000001fce42b7c0 start 0000000010030000 end 0000000010040000
next c000001fce42b580 prev c000001fce42b880 mm c000001fce40fa00
prot 8000000000000104 anon_vma           (null) vm_ops           (null)
pgoff 1003 file           (null) private_data           (null)
flags: 0x100073(read|write|mayread|maywrite|mayexec|account)

Will double check the debug patch.

----------------------------------------------
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index d8c5657..ccef8fd 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -41,6 +41,7 @@
 #include <linux/cred.h>
 #include <linux/dax.h>
 #include <linux/uaccess.h>
+#include <linux/mmdebug.h>
 #include <asm/param.h>
 #include <asm/page.h>
 
@@ -341,6 +342,10 @@ static int padzero(unsigned long elf_bss)
 
 #ifndef elf_map
 
+extern struct mm_struct *mm_ptr;
+extern bool just_init;
+extern void dump_mm_vmas(const struct mm_struct *mm);
+
 static unsigned long elf_map(struct file *filep, unsigned long addr,
 		struct elf_phdr *eppnt, int prot, int type,
 		unsigned long total_size)
@@ -372,11 +377,21 @@ 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",
+	if ((type & MAP_FIXED_NOREPLACE) && BAD_ADDR(map_addr)) {
+		struct vm_area_struct *vma;
+
+		if (strcmp(current->comm, "sed"))
+			return(map_addr);
+
+		vma = find_vma(current->mm, addr);
+		if (just_init && (mm_ptr == vma->vm_mm)) {
+			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);
 
+			dump_mm_vmas(vma->vm_mm);
+		}
+	}
 	return(map_addr);
 }
 
diff --git a/mm/mmap.c b/mm/mmap.c
index ca7b1cf..b427a5b 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -45,6 +45,7 @@
 #include <linux/moduleparam.h>
 #include <linux/pkeys.h>
 #include <linux/oom.h>
+#include <linux/mmdebug.h>
 
 #include <linux/uaccess.h>
 #include <asm/cacheflush.h>
@@ -1611,6 +1612,25 @@ static inline int accountable_mapping(struct file *file, vm_flags_t vm_flags)
 	return (vm_flags & (VM_NORESERVE | VM_SHARED | VM_WRITE)) == VM_WRITE;
 }
 
+struct mm_struct *mm_ptr;
+bool just_init;
+EXPORT_SYMBOL(mm_ptr);
+EXPORT_SYMBOL(just_init);
+
+void dump_mm_vmas(const struct mm_struct *mm)
+{
+	struct vm_area_struct *vma = mm->mmap;
+	int count;
+
+	printk("Total VMAs %d on MM %lx\n", mm->map_count, (unsigned long) mm);
+
+	for (count = 0; vma && count < mm->map_count; count++, vma = vma->vm_next) {
+		printk("Details for VMA[%d] %lx\n", count + 1, (unsigned long) vma);
+		dump_vma(vma);
+	}
+}
+EXPORT_SYMBOL(dump_mm_vmas);
+
 unsigned long mmap_region(struct file *file, unsigned long addr,
 		unsigned long len, vm_flags_t vm_flags, unsigned long pgoff,
 		struct list_head *uf)
@@ -1754,6 +1774,21 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
 
 	vma_set_page_prot(vma);
 
+	if (!strcmp(current->comm, "sed")) {
+		if (!just_init) {
+			just_init = 1;
+			mm_ptr = vma->vm_mm;
+			printk("XXX: mm %lx registered\n", (unsigned long) mm_ptr);
+			dump_mm_vmas(vma->vm_mm);
+			dump_stack();
+		} else {
+			if(mm_ptr == vma->vm_mm) {
+				dump_mm_vmas(vma->vm_mm);
+				dump_stack();
+			}
+		}
+	}
+
 	return addr;
 
 unmap_and_free_vma:

^ permalink raw reply related	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-29  2:47                                         ` Anshuman Khandual
  0 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-29  2:47 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On 01/26/2018 07:34 PM, Michal Hocko wrote:
> On Fri 26-01-18 18:04:27, Anshuman Khandual wrote:
> [...]
>> I tried to instrument mmap_region() for a single instance of 'sed'
>> binary and traced all it's VMA creation. But there is no trace when
>> that 'anon' VMA got created which suddenly shows up during subsequent
>> elf_map() call eventually failing it. Please note that the following
>> VMA was never created through call into map_region() in the process
>> which is strange.
> 
> Could you share your debugging patch?

Please find the debug patch at the end.

> 
>> =================================================================
>> [    9.076867] Details for VMA[3] c000001fce42b7c0
>> [    9.076925] vma c000001fce42b7c0 start 0000000010030000 end 0000000010040000
>> next c000001fce42b580 prev c000001fce42b880 mm c000001fce40fa00
>> prot 8000000000000104 anon_vma           (null) vm_ops           (null)
>> pgoff 1003 file           (null) private_data           (null)
>> flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
>> =================================================================
> 
> Isn't this vdso or some other special mapping? It is not really an
> anonymous vma. Please hook into __install_special_mapping

Yeah, will do. Its not an anon mapping as it does not have a anon_vma
structure ?

> 
>> VMA creation for 'sed' binary
>> =============================
>> [    9.071902] XXX: mm c000001fce40fa00 registered
>>
>> [    9.071971] Total VMAs 2 on MM c000001fce40fa00
>> ----
>> [    9.072010] Details for VMA[1] c000001fce42bdc0
>> [    9.072064] vma c000001fce42bdc0 start 0000000010000000 end 0000000010020000
>> next c000001fce42b580 prev           (null) mm c000001fce40fa00
>> prot 8000000000000105 anon_vma           (null) vm_ops c008000011ddca18
>> pgoff 0 file c000001fe2969a00 private_data           (null)
>> flags: 0x875(read|exec|mayread|maywrite|mayexec|denywrite)
> 
> This one doesn't have any stack trace either... Yet it is a file
> mapping obviously. Special mappings shouldn't have any file associated.
> Strange...

IIUC, the first VMA (which seems to be an anon VMA) did not have any
stack trace and not sure how it got created.

[    9.077335] vma c000001fce42b580 start 00007fffcafe0000 end 00007fffcb010000
next           (null) prev c000001fce42b7c0 mm c000001fce40fa00
prot 8000000000000104 anon_vma c000001fce4456f0 vm_ops           (null)
pgoff 1fffffffd file           (null) private_data           (null)
flags: 0x100173(read|write|mayread|maywrite|mayexec|growsdown|account)

the subsequent ones, this

[    9.072010] Details for VMA[1] c000001fce42bdc0
[    9.072064] vma c000001fce42bdc0 start 0000000010000000 end 0000000010020000
next c000001fce42b580 prev           (null) mm c000001fce40fa00
prot 8000000000000105 anon_vma           (null) vm_ops c008000011ddca18
pgoff 0 file c000001fe2969a00 private_data           (null)
flags: 0x875(read|exec|mayread|maywrite|mayexec|denywrite)

and this (both are file mapping for sure and getting loaded from elf)

[    9.074170] Details for VMA[2] c000001fce42b880
[    9.074236] vma c000001fce42b880 start 0000000010020000 end 0000000010030000
next c000001fce42b580 prev c000001fce42bdc0 mm c000001fce40fa00
prot 8000000000000104 anon_vma           (null) vm_ops c008000011ddca18
pgoff 1 file c000001fe2969a00 private_data           (null)
flags: 0x100873(read|write|mayread|maywrite|mayexec|denywrite|account)

have similar stack traces

[    9.072839] CPU: 48 PID: 7544 Comm: sed Not tainted 4.14.0-dirty #154
[    9.072928] Call Trace:
[    9.072952] [c000001fbef37840] [c000000000b17a00] dump_stack+0xb0/0xf0 (unreliable)
[    9.073021] [c000001fbef37880] [c0000000002dbc48] mmap_region+0x718/0x720
[    9.073097] [c000001fbef37970] [c0000000002dc034] do_mmap+0x3e4/0x480
[    9.073179] [c000001fbef379f0] [c0000000002a96c8] vm_mmap_pgoff+0xe8/0x120
[    9.073268] [c000001fbef37ac0] [c0000000003cf378] elf_map+0x98/0x270
[    9.073326] [c000001fbef37b60] [c0000000003d1258] load_elf_binary+0x6f8/0x158c
[    9.073416] [c000001fbef37c80] [c00000000035d320] search_binary_handler+0xd0/0x270
[    9.073510] [c000001fbef37d10] [c00000000035f278] do_execveat_common.isra.31+0x658/0x890
[    9.073599] [c000001fbef37df0] [c00000000035f8c0] SyS_execve+0x40/0x50
[    9.073673] [c000001fbef37e30] [c00000000000b220] system_call+0x58/0x6c

and then again this one (which causes the collision subsequently) is neither
a anon VMA nor a file VMA and does not have a stack trace either.

[    9.076867] Details for VMA[3] c000001fce42b7c0
[    9.076925] vma c000001fce42b7c0 start 0000000010030000 end 0000000010040000
next c000001fce42b580 prev c000001fce42b880 mm c000001fce40fa00
prot 8000000000000104 anon_vma           (null) vm_ops           (null)
pgoff 1003 file           (null) private_data           (null)
flags: 0x100073(read|write|mayread|maywrite|mayexec|account)

Will double check the debug patch.

----------------------------------------------
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index d8c5657..ccef8fd 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -41,6 +41,7 @@
 #include <linux/cred.h>
 #include <linux/dax.h>
 #include <linux/uaccess.h>
+#include <linux/mmdebug.h>
 #include <asm/param.h>
 #include <asm/page.h>
 
@@ -341,6 +342,10 @@ static int padzero(unsigned long elf_bss)
 
 #ifndef elf_map
 
+extern struct mm_struct *mm_ptr;
+extern bool just_init;
+extern void dump_mm_vmas(const struct mm_struct *mm);
+
 static unsigned long elf_map(struct file *filep, unsigned long addr,
 		struct elf_phdr *eppnt, int prot, int type,
 		unsigned long total_size)
@@ -372,11 +377,21 @@ 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",
+	if ((type & MAP_FIXED_NOREPLACE) && BAD_ADDR(map_addr)) {
+		struct vm_area_struct *vma;
+
+		if (strcmp(current->comm, "sed"))
+			return(map_addr);
+
+		vma = find_vma(current->mm, addr);
+		if (just_init && (mm_ptr == vma->vm_mm)) {
+			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);
 
+			dump_mm_vmas(vma->vm_mm);
+		}
+	}
 	return(map_addr);
 }
 
diff --git a/mm/mmap.c b/mm/mmap.c
index ca7b1cf..b427a5b 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -45,6 +45,7 @@
 #include <linux/moduleparam.h>
 #include <linux/pkeys.h>
 #include <linux/oom.h>
+#include <linux/mmdebug.h>
 
 #include <linux/uaccess.h>
 #include <asm/cacheflush.h>
@@ -1611,6 +1612,25 @@ static inline int accountable_mapping(struct file *file, vm_flags_t vm_flags)
 	return (vm_flags & (VM_NORESERVE | VM_SHARED | VM_WRITE)) == VM_WRITE;
 }
 
+struct mm_struct *mm_ptr;
+bool just_init;
+EXPORT_SYMBOL(mm_ptr);
+EXPORT_SYMBOL(just_init);
+
+void dump_mm_vmas(const struct mm_struct *mm)
+{
+	struct vm_area_struct *vma = mm->mmap;
+	int count;
+
+	printk("Total VMAs %d on MM %lx\n", mm->map_count, (unsigned long) mm);
+
+	for (count = 0; vma && count < mm->map_count; count++, vma = vma->vm_next) {
+		printk("Details for VMA[%d] %lx\n", count + 1, (unsigned long) vma);
+		dump_vma(vma);
+	}
+}
+EXPORT_SYMBOL(dump_mm_vmas);
+
 unsigned long mmap_region(struct file *file, unsigned long addr,
 		unsigned long len, vm_flags_t vm_flags, unsigned long pgoff,
 		struct list_head *uf)
@@ -1754,6 +1774,21 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
 
 	vma_set_page_prot(vma);
 
+	if (!strcmp(current->comm, "sed")) {
+		if (!just_init) {
+			just_init = 1;
+			mm_ptr = vma->vm_mm;
+			printk("XXX: mm %lx registered\n", (unsigned long) mm_ptr);
+			dump_mm_vmas(vma->vm_mm);
+			dump_stack();
+		} else {
+			if(mm_ptr == vma->vm_mm) {
+				dump_mm_vmas(vma->vm_mm);
+				dump_stack();
+			}
+		}
+	}
+
 	return addr;
 
 unmap_and_free_vma:

--
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>

^ permalink raw reply related	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-29  2:47                                         ` Anshuman Khandual
@ 2018-01-29  5:32                                           ` Anshuman Khandual
  -1 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-29  5:32 UTC (permalink / raw)
  To: Anshuman Khandual, Michal Hocko
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On 01/29/2018 08:17 AM, Anshuman Khandual wrote:
> On 01/26/2018 07:34 PM, Michal Hocko wrote:
>> On Fri 26-01-18 18:04:27, Anshuman Khandual wrote:
>> [...]
>>> I tried to instrument mmap_region() for a single instance of 'sed'
>>> binary and traced all it's VMA creation. But there is no trace when
>>> that 'anon' VMA got created which suddenly shows up during subsequent
>>> elf_map() call eventually failing it. Please note that the following
>>> VMA was never created through call into map_region() in the process
>>> which is strange.
>>
>> Could you share your debugging patch?
> 
> Please find the debug patch at the end.
> 
>>
>>> =================================================================
>>> [    9.076867] Details for VMA[3] c000001fce42b7c0
>>> [    9.076925] vma c000001fce42b7c0 start 0000000010030000 end 0000000010040000
>>> next c000001fce42b580 prev c000001fce42b880 mm c000001fce40fa00
>>> prot 8000000000000104 anon_vma           (null) vm_ops           (null)
>>> pgoff 1003 file           (null) private_data           (null)
>>> flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
>>> =================================================================
>>
>> Isn't this vdso or some other special mapping? It is not really an
>> anonymous vma. Please hook into __install_special_mapping
> 
> Yeah, will do. Its not an anon mapping as it does not have a anon_vma
> structure ?

Okay, this colliding VMA seems to be getting loaded from load_elf_binary()
function as well.

[    9.422410] vma c000001fceedbc40 start 0000000010030000 end 0000000010040000
next c000001fceedbe80 prev c000001fceedb700 mm c000001fceea8200
prot 8000000000000104 anon_vma           (null) vm_ops           (null)
pgoff 1003 file           (null) private_data           (null)
flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
[    9.422576] CPU: 46 PID: 7457 Comm: sed Not tainted 4.14.0-dirty #158
[    9.422610] Call Trace:
[    9.422623] [c000001fdc4f79b0] [c000000000b17ac0] dump_stack+0xb0/0xf0 (unreliable)
[    9.422670] [c000001fdc4f79f0] [c0000000002dafb8] do_brk_flags+0x2d8/0x440
[    9.422708] [c000001fdc4f7ac0] [c0000000002db3d0] vm_brk_flags+0x80/0x130
[    9.422747] [c000001fdc4f7b20] [c0000000003d23a4] set_brk+0x80/0xdc
[    9.422785] [c000001fdc4f7b60] [c0000000003d1f24] load_elf_binary+0x1304/0x158c
[    9.422830] [c000001fdc4f7c80] [c00000000035d3e0] search_binary_handler+0xd0/0x270
[    9.422881] [c000001fdc4f7d10] [c00000000035f338] do_execveat_common.isra.31+0x658/0x890
[    9.422926] [c000001fdc4f7df0] [c00000000035f980] SyS_execve+0x40/0x50
[    9.423588] [c000001fdc4f7e30] [c00000000000b220] system_call+0x58/0x6c

which is getting hit after adding some more debug.

@@ -2949,6 +2997,13 @@ static int do_brk_flags(unsigned long addr, unsigned long request, unsigned long
        if (flags & VM_LOCKED)
                mm->locked_vm += (len >> PAGE_SHIFT);
        vma->vm_flags |= VM_SOFTDIRTY;
+
+       if (!strcmp(current->comm, "sed")) {
+               if (just_init && (mm_ptr == vma->vm_mm)) {
+                       dump_vma(vma);
+                       dump_stack();
+               }
+       }
        return 0;
 }

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-29  5:32                                           ` Anshuman Khandual
  0 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-29  5:32 UTC (permalink / raw)
  To: Anshuman Khandual, Michal Hocko
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On 01/29/2018 08:17 AM, Anshuman Khandual wrote:
> On 01/26/2018 07:34 PM, Michal Hocko wrote:
>> On Fri 26-01-18 18:04:27, Anshuman Khandual wrote:
>> [...]
>>> I tried to instrument mmap_region() for a single instance of 'sed'
>>> binary and traced all it's VMA creation. But there is no trace when
>>> that 'anon' VMA got created which suddenly shows up during subsequent
>>> elf_map() call eventually failing it. Please note that the following
>>> VMA was never created through call into map_region() in the process
>>> which is strange.
>>
>> Could you share your debugging patch?
> 
> Please find the debug patch at the end.
> 
>>
>>> =================================================================
>>> [    9.076867] Details for VMA[3] c000001fce42b7c0
>>> [    9.076925] vma c000001fce42b7c0 start 0000000010030000 end 0000000010040000
>>> next c000001fce42b580 prev c000001fce42b880 mm c000001fce40fa00
>>> prot 8000000000000104 anon_vma           (null) vm_ops           (null)
>>> pgoff 1003 file           (null) private_data           (null)
>>> flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
>>> =================================================================
>>
>> Isn't this vdso or some other special mapping? It is not really an
>> anonymous vma. Please hook into __install_special_mapping
> 
> Yeah, will do. Its not an anon mapping as it does not have a anon_vma
> structure ?

Okay, this colliding VMA seems to be getting loaded from load_elf_binary()
function as well.

[    9.422410] vma c000001fceedbc40 start 0000000010030000 end 0000000010040000
next c000001fceedbe80 prev c000001fceedb700 mm c000001fceea8200
prot 8000000000000104 anon_vma           (null) vm_ops           (null)
pgoff 1003 file           (null) private_data           (null)
flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
[    9.422576] CPU: 46 PID: 7457 Comm: sed Not tainted 4.14.0-dirty #158
[    9.422610] Call Trace:
[    9.422623] [c000001fdc4f79b0] [c000000000b17ac0] dump_stack+0xb0/0xf0 (unreliable)
[    9.422670] [c000001fdc4f79f0] [c0000000002dafb8] do_brk_flags+0x2d8/0x440
[    9.422708] [c000001fdc4f7ac0] [c0000000002db3d0] vm_brk_flags+0x80/0x130
[    9.422747] [c000001fdc4f7b20] [c0000000003d23a4] set_brk+0x80/0xdc
[    9.422785] [c000001fdc4f7b60] [c0000000003d1f24] load_elf_binary+0x1304/0x158c
[    9.422830] [c000001fdc4f7c80] [c00000000035d3e0] search_binary_handler+0xd0/0x270
[    9.422881] [c000001fdc4f7d10] [c00000000035f338] do_execveat_common.isra.31+0x658/0x890
[    9.422926] [c000001fdc4f7df0] [c00000000035f980] SyS_execve+0x40/0x50
[    9.423588] [c000001fdc4f7e30] [c00000000000b220] system_call+0x58/0x6c

which is getting hit after adding some more debug.

@@ -2949,6 +2997,13 @@ static int do_brk_flags(unsigned long addr, unsigned long request, unsigned long
        if (flags & VM_LOCKED)
                mm->locked_vm += (len >> PAGE_SHIFT);
        vma->vm_flags |= VM_SOFTDIRTY;
+
+       if (!strcmp(current->comm, "sed")) {
+               if (just_init && (mm_ptr == vma->vm_mm)) {
+                       dump_vma(vma);
+                       dump_stack();
+               }
+       }
        return 0;
 }

--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-29  5:32                                           ` Anshuman Khandual
@ 2018-01-29 13:22                                             ` Michal Hocko
  -1 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-29 13:22 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On Mon 29-01-18 11:02:09, Anshuman Khandual wrote:
> On 01/29/2018 08:17 AM, Anshuman Khandual wrote:
> > On 01/26/2018 07:34 PM, Michal Hocko wrote:
> >> On Fri 26-01-18 18:04:27, Anshuman Khandual wrote:
> >> [...]
> >>> I tried to instrument mmap_region() for a single instance of 'sed'
> >>> binary and traced all it's VMA creation. But there is no trace when
> >>> that 'anon' VMA got created which suddenly shows up during subsequent
> >>> elf_map() call eventually failing it. Please note that the following
> >>> VMA was never created through call into map_region() in the process
> >>> which is strange.
> >>
> >> Could you share your debugging patch?
> > 
> > Please find the debug patch at the end.
> > 
> >>
> >>> =================================================================
> >>> [    9.076867] Details for VMA[3] c000001fce42b7c0
> >>> [    9.076925] vma c000001fce42b7c0 start 0000000010030000 end 0000000010040000
> >>> next c000001fce42b580 prev c000001fce42b880 mm c000001fce40fa00
> >>> prot 8000000000000104 anon_vma           (null) vm_ops           (null)
> >>> pgoff 1003 file           (null) private_data           (null)
> >>> flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
> >>> =================================================================
> >>
> >> Isn't this vdso or some other special mapping? It is not really an
> >> anonymous vma. Please hook into __install_special_mapping
> > 
> > Yeah, will do. Its not an anon mapping as it does not have a anon_vma
> > structure ?
> 
> Okay, this colliding VMA seems to be getting loaded from load_elf_binary()
> function as well.
> 
> [    9.422410] vma c000001fceedbc40 start 0000000010030000 end 0000000010040000
> next c000001fceedbe80 prev c000001fceedb700 mm c000001fceea8200
> prot 8000000000000104 anon_vma           (null) vm_ops           (null)
> pgoff 1003 file           (null) private_data           (null)
> flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
> [    9.422576] CPU: 46 PID: 7457 Comm: sed Not tainted 4.14.0-dirty #158
> [    9.422610] Call Trace:
> [    9.422623] [c000001fdc4f79b0] [c000000000b17ac0] dump_stack+0xb0/0xf0 (unreliable)
> [    9.422670] [c000001fdc4f79f0] [c0000000002dafb8] do_brk_flags+0x2d8/0x440
> [    9.422708] [c000001fdc4f7ac0] [c0000000002db3d0] vm_brk_flags+0x80/0x130
> [    9.422747] [c000001fdc4f7b20] [c0000000003d23a4] set_brk+0x80/0xdc
> [    9.422785] [c000001fdc4f7b60] [c0000000003d1f24] load_elf_binary+0x1304/0x158c
> [    9.422830] [c000001fdc4f7c80] [c00000000035d3e0] search_binary_handler+0xd0/0x270
> [    9.422881] [c000001fdc4f7d10] [c00000000035f338] do_execveat_common.isra.31+0x658/0x890
> [    9.422926] [c000001fdc4f7df0] [c00000000035f980] SyS_execve+0x40/0x50
> [    9.423588] [c000001fdc4f7e30] [c00000000000b220] system_call+0x58/0x6c
> 
> which is getting hit after adding some more debug.

Voila! So your binary simply overrides brk by elf segments. That sounds
like the exactly the thing that the patch is supposed to protect from.
Why this is the case I dunno. It is just clear that either brk or
elf base are not put to the proper place. Something to get fixed. You
are probably just lucky that brk allocations do not spil over to elf
mappings.

> @@ -2949,6 +2997,13 @@ static int do_brk_flags(unsigned long addr, unsigned long request, unsigned long
>         if (flags & VM_LOCKED)
>                 mm->locked_vm += (len >> PAGE_SHIFT);
>         vma->vm_flags |= VM_SOFTDIRTY;
> +
> +       if (!strcmp(current->comm, "sed")) {
> +               if (just_init && (mm_ptr == vma->vm_mm)) {
> +                       dump_vma(vma);
> +                       dump_stack();
> +               }
> +       }
>         return 0;
>  }
> 
> --
> 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>

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-29 13:22                                             ` Michal Hocko
  0 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-29 13:22 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On Mon 29-01-18 11:02:09, Anshuman Khandual wrote:
> On 01/29/2018 08:17 AM, Anshuman Khandual wrote:
> > On 01/26/2018 07:34 PM, Michal Hocko wrote:
> >> On Fri 26-01-18 18:04:27, Anshuman Khandual wrote:
> >> [...]
> >>> I tried to instrument mmap_region() for a single instance of 'sed'
> >>> binary and traced all it's VMA creation. But there is no trace when
> >>> that 'anon' VMA got created which suddenly shows up during subsequent
> >>> elf_map() call eventually failing it. Please note that the following
> >>> VMA was never created through call into map_region() in the process
> >>> which is strange.
> >>
> >> Could you share your debugging patch?
> > 
> > Please find the debug patch at the end.
> > 
> >>
> >>> =================================================================
> >>> [    9.076867] Details for VMA[3] c000001fce42b7c0
> >>> [    9.076925] vma c000001fce42b7c0 start 0000000010030000 end 0000000010040000
> >>> next c000001fce42b580 prev c000001fce42b880 mm c000001fce40fa00
> >>> prot 8000000000000104 anon_vma           (null) vm_ops           (null)
> >>> pgoff 1003 file           (null) private_data           (null)
> >>> flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
> >>> =================================================================
> >>
> >> Isn't this vdso or some other special mapping? It is not really an
> >> anonymous vma. Please hook into __install_special_mapping
> > 
> > Yeah, will do. Its not an anon mapping as it does not have a anon_vma
> > structure ?
> 
> Okay, this colliding VMA seems to be getting loaded from load_elf_binary()
> function as well.
> 
> [    9.422410] vma c000001fceedbc40 start 0000000010030000 end 0000000010040000
> next c000001fceedbe80 prev c000001fceedb700 mm c000001fceea8200
> prot 8000000000000104 anon_vma           (null) vm_ops           (null)
> pgoff 1003 file           (null) private_data           (null)
> flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
> [    9.422576] CPU: 46 PID: 7457 Comm: sed Not tainted 4.14.0-dirty #158
> [    9.422610] Call Trace:
> [    9.422623] [c000001fdc4f79b0] [c000000000b17ac0] dump_stack+0xb0/0xf0 (unreliable)
> [    9.422670] [c000001fdc4f79f0] [c0000000002dafb8] do_brk_flags+0x2d8/0x440
> [    9.422708] [c000001fdc4f7ac0] [c0000000002db3d0] vm_brk_flags+0x80/0x130
> [    9.422747] [c000001fdc4f7b20] [c0000000003d23a4] set_brk+0x80/0xdc
> [    9.422785] [c000001fdc4f7b60] [c0000000003d1f24] load_elf_binary+0x1304/0x158c
> [    9.422830] [c000001fdc4f7c80] [c00000000035d3e0] search_binary_handler+0xd0/0x270
> [    9.422881] [c000001fdc4f7d10] [c00000000035f338] do_execveat_common.isra.31+0x658/0x890
> [    9.422926] [c000001fdc4f7df0] [c00000000035f980] SyS_execve+0x40/0x50
> [    9.423588] [c000001fdc4f7e30] [c00000000000b220] system_call+0x58/0x6c
> 
> which is getting hit after adding some more debug.

Voila! So your binary simply overrides brk by elf segments. That sounds
like the exactly the thing that the patch is supposed to protect from.
Why this is the case I dunno. It is just clear that either brk or
elf base are not put to the proper place. Something to get fixed. You
are probably just lucky that brk allocations do not spil over to elf
mappings.

> @@ -2949,6 +2997,13 @@ static int do_brk_flags(unsigned long addr, unsigned long request, unsigned long
>         if (flags & VM_LOCKED)
>                 mm->locked_vm += (len >> PAGE_SHIFT);
>         vma->vm_flags |= VM_SOFTDIRTY;
> +
> +       if (!strcmp(current->comm, "sed")) {
> +               if (just_init && (mm_ptr == vma->vm_mm)) {
> +                       dump_vma(vma);
> +                       dump_stack();
> +               }
> +       }
>         return 0;
>  }
> 
> --
> 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>

-- 
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-29 13:22                                             ` Michal Hocko
@ 2018-01-30  3:35                                               ` Michael Ellerman
  -1 siblings, 0 replies; 82+ messages in thread
From: Michael Ellerman @ 2018-01-30  3:35 UTC (permalink / raw)
  To: Michal Hocko, akpm
  Cc: Anshuman Khandual, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

Michal Hocko <mhocko@kernel.org> writes:

> On Mon 29-01-18 11:02:09, Anshuman Khandual wrote:
>> On 01/29/2018 08:17 AM, Anshuman Khandual wrote:
>> > On 01/26/2018 07:34 PM, Michal Hocko wrote:
>> >> On Fri 26-01-18 18:04:27, Anshuman Khandual wrote:
>> >> [...]
>> >>> I tried to instrument mmap_region() for a single instance of 'sed'
>> >>> binary and traced all it's VMA creation. But there is no trace when
>> >>> that 'anon' VMA got created which suddenly shows up during subsequent
>> >>> elf_map() call eventually failing it. Please note that the following
>> >>> VMA was never created through call into map_region() in the process
>> >>> which is strange.
...
>> 
>> Okay, this colliding VMA seems to be getting loaded from load_elf_binary()
>> function as well.
>> 
>> [    9.422410] vma c000001fceedbc40 start 0000000010030000 end 0000000010040000
>> next c000001fceedbe80 prev c000001fceedb700 mm c000001fceea8200
>> prot 8000000000000104 anon_vma           (null) vm_ops           (null)
>> pgoff 1003 file           (null) private_data           (null)
>> flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
>> [    9.422576] CPU: 46 PID: 7457 Comm: sed Not tainted 4.14.0-dirty #158
>> [    9.422610] Call Trace:
>> [    9.422623] [c000001fdc4f79b0] [c000000000b17ac0] dump_stack+0xb0/0xf0 (unreliable)
>> [    9.422670] [c000001fdc4f79f0] [c0000000002dafb8] do_brk_flags+0x2d8/0x440
>> [    9.422708] [c000001fdc4f7ac0] [c0000000002db3d0] vm_brk_flags+0x80/0x130
>> [    9.422747] [c000001fdc4f7b20] [c0000000003d23a4] set_brk+0x80/0xdc
>> [    9.422785] [c000001fdc4f7b60] [c0000000003d1f24] load_elf_binary+0x1304/0x158c
>> [    9.422830] [c000001fdc4f7c80] [c00000000035d3e0] search_binary_handler+0xd0/0x270
>> [    9.422881] [c000001fdc4f7d10] [c00000000035f338] do_execveat_common.isra.31+0x658/0x890
>> [    9.422926] [c000001fdc4f7df0] [c00000000035f980] SyS_execve+0x40/0x50
>> [    9.423588] [c000001fdc4f7e30] [c00000000000b220] system_call+0x58/0x6c
>> 
>> which is getting hit after adding some more debug.
>
> Voila! So your binary simply overrides brk by elf segments. That sounds
> like the exactly the thing that the patch is supposed to protect from.
> Why this is the case I dunno. It is just clear that either brk or
> elf base are not put to the proper place. Something to get fixed. You
> are probably just lucky that brk allocations do not spil over to elf
> mappings.

It is something to get fixed, but we can't retrospectively fix the
existing binaries sitting on peoples' systems.

Possibly powerpc arch code is doing something with the mmap layout or
something else that is confusing the ELF loader, in which case we should
fix that.

But if not then the only solution is for the ELF loader to be more
tolerant of this situation.

So for 4.16 this patch either needs to be dropped, or reworked such that
powerpc can opt out of it.

cheers

--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-30  3:35                                               ` Michael Ellerman
  0 siblings, 0 replies; 82+ messages in thread
From: Michael Ellerman @ 2018-01-30  3:35 UTC (permalink / raw)
  To: Michal Hocko, akpm
  Cc: Anshuman Khandual, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

Michal Hocko <mhocko@kernel.org> writes:

> On Mon 29-01-18 11:02:09, Anshuman Khandual wrote:
>> On 01/29/2018 08:17 AM, Anshuman Khandual wrote:
>> > On 01/26/2018 07:34 PM, Michal Hocko wrote:
>> >> On Fri 26-01-18 18:04:27, Anshuman Khandual wrote:
>> >> [...]
>> >>> I tried to instrument mmap_region() for a single instance of 'sed'
>> >>> binary and traced all it's VMA creation. But there is no trace when
>> >>> that 'anon' VMA got created which suddenly shows up during subsequent
>> >>> elf_map() call eventually failing it. Please note that the following
>> >>> VMA was never created through call into map_region() in the process
>> >>> which is strange.
...
>> 
>> Okay, this colliding VMA seems to be getting loaded from load_elf_binary()
>> function as well.
>> 
>> [    9.422410] vma c000001fceedbc40 start 0000000010030000 end 0000000010040000
>> next c000001fceedbe80 prev c000001fceedb700 mm c000001fceea8200
>> prot 8000000000000104 anon_vma           (null) vm_ops           (null)
>> pgoff 1003 file           (null) private_data           (null)
>> flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
>> [    9.422576] CPU: 46 PID: 7457 Comm: sed Not tainted 4.14.0-dirty #158
>> [    9.422610] Call Trace:
>> [    9.422623] [c000001fdc4f79b0] [c000000000b17ac0] dump_stack+0xb0/0xf0 (unreliable)
>> [    9.422670] [c000001fdc4f79f0] [c0000000002dafb8] do_brk_flags+0x2d8/0x440
>> [    9.422708] [c000001fdc4f7ac0] [c0000000002db3d0] vm_brk_flags+0x80/0x130
>> [    9.422747] [c000001fdc4f7b20] [c0000000003d23a4] set_brk+0x80/0xdc
>> [    9.422785] [c000001fdc4f7b60] [c0000000003d1f24] load_elf_binary+0x1304/0x158c
>> [    9.422830] [c000001fdc4f7c80] [c00000000035d3e0] search_binary_handler+0xd0/0x270
>> [    9.422881] [c000001fdc4f7d10] [c00000000035f338] do_execveat_common.isra.31+0x658/0x890
>> [    9.422926] [c000001fdc4f7df0] [c00000000035f980] SyS_execve+0x40/0x50
>> [    9.423588] [c000001fdc4f7e30] [c00000000000b220] system_call+0x58/0x6c
>> 
>> which is getting hit after adding some more debug.
>
> Voila! So your binary simply overrides brk by elf segments. That sounds
> like the exactly the thing that the patch is supposed to protect from.
> Why this is the case I dunno. It is just clear that either brk or
> elf base are not put to the proper place. Something to get fixed. You
> are probably just lucky that brk allocations do not spil over to elf
> mappings.

It is something to get fixed, but we can't retrospectively fix the
existing binaries sitting on peoples' systems.

Possibly powerpc arch code is doing something with the mmap layout or
something else that is confusing the ELF loader, in which case we should
fix that.

But if not then the only solution is for the ELF loader to be more
tolerant of this situation.

So for 4.16 this patch either needs to be dropped, or reworked such that
powerpc can opt out of it.

cheers

--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-30  3:35                                               ` Michael Ellerman
@ 2018-01-30  9:42                                                 ` Michal Hocko
  -1 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-30  9:42 UTC (permalink / raw)
  To: Michael Ellerman, Anshuman Khandual
  Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, broonie

On Tue 30-01-18 14:35:12, Michael Ellerman wrote:
> Michal Hocko <mhocko@kernel.org> writes:
> 
> > On Mon 29-01-18 11:02:09, Anshuman Khandual wrote:
> >> On 01/29/2018 08:17 AM, Anshuman Khandual wrote:
> >> > On 01/26/2018 07:34 PM, Michal Hocko wrote:
> >> >> On Fri 26-01-18 18:04:27, Anshuman Khandual wrote:
> >> >> [...]
> >> >>> I tried to instrument mmap_region() for a single instance of 'sed'
> >> >>> binary and traced all it's VMA creation. But there is no trace when
> >> >>> that 'anon' VMA got created which suddenly shows up during subsequent
> >> >>> elf_map() call eventually failing it. Please note that the following
> >> >>> VMA was never created through call into map_region() in the process
> >> >>> which is strange.
> ...
> >> 
> >> Okay, this colliding VMA seems to be getting loaded from load_elf_binary()
> >> function as well.
> >> 
> >> [    9.422410] vma c000001fceedbc40 start 0000000010030000 end 0000000010040000
> >> next c000001fceedbe80 prev c000001fceedb700 mm c000001fceea8200
> >> prot 8000000000000104 anon_vma           (null) vm_ops           (null)
> >> pgoff 1003 file           (null) private_data           (null)
> >> flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
> >> [    9.422576] CPU: 46 PID: 7457 Comm: sed Not tainted 4.14.0-dirty #158
> >> [    9.422610] Call Trace:
> >> [    9.422623] [c000001fdc4f79b0] [c000000000b17ac0] dump_stack+0xb0/0xf0 (unreliable)
> >> [    9.422670] [c000001fdc4f79f0] [c0000000002dafb8] do_brk_flags+0x2d8/0x440
> >> [    9.422708] [c000001fdc4f7ac0] [c0000000002db3d0] vm_brk_flags+0x80/0x130
> >> [    9.422747] [c000001fdc4f7b20] [c0000000003d23a4] set_brk+0x80/0xdc
> >> [    9.422785] [c000001fdc4f7b60] [c0000000003d1f24] load_elf_binary+0x1304/0x158c
> >> [    9.422830] [c000001fdc4f7c80] [c00000000035d3e0] search_binary_handler+0xd0/0x270
> >> [    9.422881] [c000001fdc4f7d10] [c00000000035f338] do_execveat_common.isra.31+0x658/0x890
> >> [    9.422926] [c000001fdc4f7df0] [c00000000035f980] SyS_execve+0x40/0x50
> >> [    9.423588] [c000001fdc4f7e30] [c00000000000b220] system_call+0x58/0x6c
> >> 
> >> which is getting hit after adding some more debug.
> >
> > Voila! So your binary simply overrides brk by elf segments. That sounds
> > like the exactly the thing that the patch is supposed to protect from.
> > Why this is the case I dunno. It is just clear that either brk or
> > elf base are not put to the proper place. Something to get fixed. You
> > are probably just lucky that brk allocations do not spil over to elf
> > mappings.
> 
> It is something to get fixed, but we can't retrospectively fix the
> existing binaries sitting on peoples' systems.

Yeah. Can we identify those somehow? Are they something people can
easily come across?

> Possibly powerpc arch code is doing something with the mmap layout or
> something else that is confusing the ELF loader, in which case we should
> fix that.

Yes this definitely should be fixed. How can elf loader completely
overlap brk mapping?

> But if not then the only solution is for the ELF loader to be more
> tolerant of this situation.
> 
> So for 4.16 this patch either needs to be dropped, or reworked such that
> powerpc can opt out of it.

Yeah, let's hold on merging this until we understand what the heck is
going on here. If this turnes to be unfixable I will think of a way for
ppc to opt out.

Anshuman, could you try to run
sed 's@^@@' /proc/self/smaps
on a system with MAP_FIXED_NOREPLACE reverted?
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-30  9:42                                                 ` Michal Hocko
  0 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-30  9:42 UTC (permalink / raw)
  To: Michael Ellerman, Anshuman Khandual
  Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, broonie

On Tue 30-01-18 14:35:12, Michael Ellerman wrote:
> Michal Hocko <mhocko@kernel.org> writes:
> 
> > On Mon 29-01-18 11:02:09, Anshuman Khandual wrote:
> >> On 01/29/2018 08:17 AM, Anshuman Khandual wrote:
> >> > On 01/26/2018 07:34 PM, Michal Hocko wrote:
> >> >> On Fri 26-01-18 18:04:27, Anshuman Khandual wrote:
> >> >> [...]
> >> >>> I tried to instrument mmap_region() for a single instance of 'sed'
> >> >>> binary and traced all it's VMA creation. But there is no trace when
> >> >>> that 'anon' VMA got created which suddenly shows up during subsequent
> >> >>> elf_map() call eventually failing it. Please note that the following
> >> >>> VMA was never created through call into map_region() in the process
> >> >>> which is strange.
> ...
> >> 
> >> Okay, this colliding VMA seems to be getting loaded from load_elf_binary()
> >> function as well.
> >> 
> >> [    9.422410] vma c000001fceedbc40 start 0000000010030000 end 0000000010040000
> >> next c000001fceedbe80 prev c000001fceedb700 mm c000001fceea8200
> >> prot 8000000000000104 anon_vma           (null) vm_ops           (null)
> >> pgoff 1003 file           (null) private_data           (null)
> >> flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
> >> [    9.422576] CPU: 46 PID: 7457 Comm: sed Not tainted 4.14.0-dirty #158
> >> [    9.422610] Call Trace:
> >> [    9.422623] [c000001fdc4f79b0] [c000000000b17ac0] dump_stack+0xb0/0xf0 (unreliable)
> >> [    9.422670] [c000001fdc4f79f0] [c0000000002dafb8] do_brk_flags+0x2d8/0x440
> >> [    9.422708] [c000001fdc4f7ac0] [c0000000002db3d0] vm_brk_flags+0x80/0x130
> >> [    9.422747] [c000001fdc4f7b20] [c0000000003d23a4] set_brk+0x80/0xdc
> >> [    9.422785] [c000001fdc4f7b60] [c0000000003d1f24] load_elf_binary+0x1304/0x158c
> >> [    9.422830] [c000001fdc4f7c80] [c00000000035d3e0] search_binary_handler+0xd0/0x270
> >> [    9.422881] [c000001fdc4f7d10] [c00000000035f338] do_execveat_common.isra.31+0x658/0x890
> >> [    9.422926] [c000001fdc4f7df0] [c00000000035f980] SyS_execve+0x40/0x50
> >> [    9.423588] [c000001fdc4f7e30] [c00000000000b220] system_call+0x58/0x6c
> >> 
> >> which is getting hit after adding some more debug.
> >
> > Voila! So your binary simply overrides brk by elf segments. That sounds
> > like the exactly the thing that the patch is supposed to protect from.
> > Why this is the case I dunno. It is just clear that either brk or
> > elf base are not put to the proper place. Something to get fixed. You
> > are probably just lucky that brk allocations do not spil over to elf
> > mappings.
> 
> It is something to get fixed, but we can't retrospectively fix the
> existing binaries sitting on peoples' systems.

Yeah. Can we identify those somehow? Are they something people can
easily come across?

> Possibly powerpc arch code is doing something with the mmap layout or
> something else that is confusing the ELF loader, in which case we should
> fix that.

Yes this definitely should be fixed. How can elf loader completely
overlap brk mapping?

> But if not then the only solution is for the ELF loader to be more
> tolerant of this situation.
> 
> So for 4.16 this patch either needs to be dropped, or reworked such that
> powerpc can opt out of it.

Yeah, let's hold on merging this until we understand what the heck is
going on here. If this turnes to be unfixable I will think of a way for
ppc to opt out.

Anshuman, could you try to run
sed 's@^@@' /proc/self/smaps
on a system with MAP_FIXED_NOREPLACE reverted?
-- 
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-30  9:42                                                 ` Michal Hocko
@ 2018-01-31  5:05                                                   ` Anshuman Khandual
  -1 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-31  5:05 UTC (permalink / raw)
  To: Michal Hocko, Michael Ellerman, Anshuman Khandual
  Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, broonie

On 01/30/2018 03:12 PM, Michal Hocko wrote:
> On Tue 30-01-18 14:35:12, Michael Ellerman wrote:
>> Michal Hocko <mhocko@kernel.org> writes:
>>
>>> On Mon 29-01-18 11:02:09, Anshuman Khandual wrote:
>>>> On 01/29/2018 08:17 AM, Anshuman Khandual wrote:
>>>>> On 01/26/2018 07:34 PM, Michal Hocko wrote:
>>>>>> On Fri 26-01-18 18:04:27, Anshuman Khandual wrote:
>>>>>> [...]
>>>>>>> I tried to instrument mmap_region() for a single instance of 'sed'
>>>>>>> binary and traced all it's VMA creation. But there is no trace when
>>>>>>> that 'anon' VMA got created which suddenly shows up during subsequent
>>>>>>> elf_map() call eventually failing it. Please note that the following
>>>>>>> VMA was never created through call into map_region() in the process
>>>>>>> which is strange.
>> ...
>>>>
>>>> Okay, this colliding VMA seems to be getting loaded from load_elf_binary()
>>>> function as well.
>>>>
>>>> [    9.422410] vma c000001fceedbc40 start 0000000010030000 end 0000000010040000
>>>> next c000001fceedbe80 prev c000001fceedb700 mm c000001fceea8200
>>>> prot 8000000000000104 anon_vma           (null) vm_ops           (null)
>>>> pgoff 1003 file           (null) private_data           (null)
>>>> flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
>>>> [    9.422576] CPU: 46 PID: 7457 Comm: sed Not tainted 4.14.0-dirty #158
>>>> [    9.422610] Call Trace:
>>>> [    9.422623] [c000001fdc4f79b0] [c000000000b17ac0] dump_stack+0xb0/0xf0 (unreliable)
>>>> [    9.422670] [c000001fdc4f79f0] [c0000000002dafb8] do_brk_flags+0x2d8/0x440
>>>> [    9.422708] [c000001fdc4f7ac0] [c0000000002db3d0] vm_brk_flags+0x80/0x130
>>>> [    9.422747] [c000001fdc4f7b20] [c0000000003d23a4] set_brk+0x80/0xdc
>>>> [    9.422785] [c000001fdc4f7b60] [c0000000003d1f24] load_elf_binary+0x1304/0x158c
>>>> [    9.422830] [c000001fdc4f7c80] [c00000000035d3e0] search_binary_handler+0xd0/0x270
>>>> [    9.422881] [c000001fdc4f7d10] [c00000000035f338] do_execveat_common.isra.31+0x658/0x890
>>>> [    9.422926] [c000001fdc4f7df0] [c00000000035f980] SyS_execve+0x40/0x50
>>>> [    9.423588] [c000001fdc4f7e30] [c00000000000b220] system_call+0x58/0x6c
>>>>
>>>> which is getting hit after adding some more debug.
>>>
>>> Voila! So your binary simply overrides brk by elf segments. That sounds
>>> like the exactly the thing that the patch is supposed to protect from.
>>> Why this is the case I dunno. It is just clear that either brk or
>>> elf base are not put to the proper place. Something to get fixed. You
>>> are probably just lucky that brk allocations do not spil over to elf
>>> mappings.
>>
>> It is something to get fixed, but we can't retrospectively fix the
>> existing binaries sitting on peoples' systems.
> 
> Yeah. Can we identify those somehow? Are they something people can
> easily come across?
> 
>> Possibly powerpc arch code is doing something with the mmap layout or
>> something else that is confusing the ELF loader, in which case we should
>> fix that.
> 
> Yes this definitely should be fixed. How can elf loader completely
> overlap brk mapping?
> 
>> But if not then the only solution is for the ELF loader to be more
>> tolerant of this situation.
>>
>> So for 4.16 this patch either needs to be dropped, or reworked such that
>> powerpc can opt out of it.
> 
> Yeah, let's hold on merging this until we understand what the heck is
> going on here. If this turnes to be unfixable I will think of a way for
> ppc to opt out.
> 
> Anshuman, could you try to run
> sed 's@^@@' /proc/self/smaps
> on a system with MAP_FIXED_NOREPLACE reverted?
> 

After reverting the following commits from mmotm-2018-01-25-16-20 tag.

67caea694ba5965a52a61fdad495d847f03c4025 ("mm-introduce-map_fixed_safe-fix")
64da2e0c134ecf3936a4c36b949bcf2cdc98977e ("fs-elf-drop-map_fixed-usage-from-elf_map-fix-fix")
645983ab6ca7fd644f52b4c55462b91940012595 ("mm: don't use the same value for MAP_FIXED_NOREPLACE and MAP_SYNC")
d77bab291ac435aab91fa214b85efa74a26c9c22 ("fs-elf-drop-map_fixed-usage-from-elf_map-checkpatch-fixes")
a75c5f92d9ecb21d3299cc7db48e401cbf335c34 ("fs, elf: drop MAP_FIXED usage from elf_map")
00906d029ffe515221e3939b222c237026af2903 ("mm: introduce MAP_FIXED_NOREPLACE")

$sed 's@^@@' /proc/self/smaps
-------------------------------------------
10000000-10020000 r-xp 00000000 fd:00 10558                              /usr/bin/sed
Size:                128 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                 128 kB
Pss:                 128 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:       128 kB
Private_Dirty:         0 kB
Referenced:          128 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:              128 kB
VmFlags: rd ex mr mw me dw 
10020000-10030000 r--p 00010000 fd:00 10558                              /usr/bin/sed
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd mr mw me dw ac 
10030000-10040000 rw-p 00020000 fd:00 10558                              /usr/bin/sed
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd wr mr mw me dw ac 
2cbb0000-2cbe0000 rw-p 00000000 00:00 0                                  [heap]
Size:                192 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd wr mr mw me ac 
7fff7f9c0000-7fff7f9e0000 rw-p 00000000 00:00 0 
Size:                128 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                 128 kB
Pss:                 128 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:       128 kB
Referenced:          128 kB
Anonymous:           128 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:              128 kB
VmFlags: rd wr mr mw me ac 
7fff7f9e0000-7fff86280000 r--p 00000000 fd:00 33660156                   /usr/lib/locale/locale-archive
Size:             107136 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                 384 kB
Pss:                  37 kB
Shared_Clean:        384 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:          384 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               37 kB
VmFlags: rd mr mw me 
7fff86280000-7fff86290000 r-xp 00000000 fd:00 33660115                   /usr/lib64/libdl-2.17.so
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                   2 kB
Shared_Clean:         64 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:           64 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                2 kB
VmFlags: rd ex mr mw me 
7fff86290000-7fff862a0000 r--p 00000000 fd:00 33660115                   /usr/lib64/libdl-2.17.so
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd mr mw me ac 
7fff862a0000-7fff862b0000 rw-p 00010000 fd:00 33660115                   /usr/lib64/libdl-2.17.so
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd wr mr mw me ac 
7fff862b0000-7fff86300000 r-xp 00000000 fd:00 33594504                   /usr/lib64/libpcre.so.1.2.0
Size:                320 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                   2 kB
Shared_Clean:         64 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:           64 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                2 kB
VmFlags: rd ex mr mw me 
7fff86300000-7fff86310000 r--p 00040000 fd:00 33594504                   /usr/lib64/libpcre.so.1.2.0
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd mr mw me ac 
7fff86310000-7fff86320000 rw-p 00050000 fd:00 33594504                   /usr/lib64/libpcre.so.1.2.0
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd wr mr mw me ac 
7fff86320000-7fff864f0000 r-xp 00000000 fd:00 33660109                   /usr/lib64/libc-2.17.so
Size:               1856 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                1280 kB
Pss:                  45 kB
Shared_Clean:       1280 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:         1280 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               45 kB
VmFlags: rd ex mr mw me 
7fff864f0000-7fff86500000 r--p 001c0000 fd:00 33660109                   /usr/lib64/libc-2.17.so
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd mr mw me ac 
7fff86500000-7fff86510000 rw-p 001d0000 fd:00 33660109                   /usr/lib64/libc-2.17.so
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd wr mr mw me ac 
7fff86510000-7fff86540000 r-xp 00000000 fd:00 33594516                   /usr/lib64/libselinux.so.1
Size:                192 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                 192 kB
Pss:                   8 kB
Shared_Clean:        192 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:          192 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                8 kB
VmFlags: rd ex mr mw me 
7fff86540000-7fff86550000 r--p 00020000 fd:00 33594516                   /usr/lib64/libselinux.so.1
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd mr mw me ac 
7fff86550000-7fff86560000 rw-p 00030000 fd:00 33594516                   /usr/lib64/libselinux.so.1
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd wr mr mw me ac 
7fff86560000-7fff86570000 r--s 00000000 fd:00 67194934                   /usr/lib64/gconv/gconv-modules.cache
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  12 kB
Shared_Clean:         64 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:           64 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               12 kB
VmFlags: rd mr me ms 
7fff86570000-7fff86590000 r-xp 00000000 00:00 0                          [vdso]
Size:                128 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                   1 kB
Shared_Clean:         64 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:           64 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                1 kB
VmFlags: rd ex mr mw me de 
7fff86590000-7fff865c0000 r-xp 00000000 fd:00 33660102                   /usr/lib64/ld-2.17.so
Size:                192 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                 192 kB
Pss:                   6 kB
Shared_Clean:        192 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:          192 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                6 kB
VmFlags: rd ex mr mw me dw 
7fff865c0000-7fff865d0000 r--p 00020000 fd:00 33660102                   /usr/lib64/ld-2.17.so
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd mr mw me dw ac 
7fff865d0000-7fff865e0000 rw-p 00030000 fd:00 33660102                   /usr/lib64/ld-2.17.so
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd wr mr mw me dw ac 
7fffd27a0000-7fffd27d0000 rw-p 00000000 00:00 0                          [stack]
Size:                192 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd wr mr mw me gd ac 

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-31  5:05                                                   ` Anshuman Khandual
  0 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-01-31  5:05 UTC (permalink / raw)
  To: Michal Hocko, Michael Ellerman, Anshuman Khandual
  Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
	linux-next, sfr, broonie

On 01/30/2018 03:12 PM, Michal Hocko wrote:
> On Tue 30-01-18 14:35:12, Michael Ellerman wrote:
>> Michal Hocko <mhocko@kernel.org> writes:
>>
>>> On Mon 29-01-18 11:02:09, Anshuman Khandual wrote:
>>>> On 01/29/2018 08:17 AM, Anshuman Khandual wrote:
>>>>> On 01/26/2018 07:34 PM, Michal Hocko wrote:
>>>>>> On Fri 26-01-18 18:04:27, Anshuman Khandual wrote:
>>>>>> [...]
>>>>>>> I tried to instrument mmap_region() for a single instance of 'sed'
>>>>>>> binary and traced all it's VMA creation. But there is no trace when
>>>>>>> that 'anon' VMA got created which suddenly shows up during subsequent
>>>>>>> elf_map() call eventually failing it. Please note that the following
>>>>>>> VMA was never created through call into map_region() in the process
>>>>>>> which is strange.
>> ...
>>>>
>>>> Okay, this colliding VMA seems to be getting loaded from load_elf_binary()
>>>> function as well.
>>>>
>>>> [    9.422410] vma c000001fceedbc40 start 0000000010030000 end 0000000010040000
>>>> next c000001fceedbe80 prev c000001fceedb700 mm c000001fceea8200
>>>> prot 8000000000000104 anon_vma           (null) vm_ops           (null)
>>>> pgoff 1003 file           (null) private_data           (null)
>>>> flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
>>>> [    9.422576] CPU: 46 PID: 7457 Comm: sed Not tainted 4.14.0-dirty #158
>>>> [    9.422610] Call Trace:
>>>> [    9.422623] [c000001fdc4f79b0] [c000000000b17ac0] dump_stack+0xb0/0xf0 (unreliable)
>>>> [    9.422670] [c000001fdc4f79f0] [c0000000002dafb8] do_brk_flags+0x2d8/0x440
>>>> [    9.422708] [c000001fdc4f7ac0] [c0000000002db3d0] vm_brk_flags+0x80/0x130
>>>> [    9.422747] [c000001fdc4f7b20] [c0000000003d23a4] set_brk+0x80/0xdc
>>>> [    9.422785] [c000001fdc4f7b60] [c0000000003d1f24] load_elf_binary+0x1304/0x158c
>>>> [    9.422830] [c000001fdc4f7c80] [c00000000035d3e0] search_binary_handler+0xd0/0x270
>>>> [    9.422881] [c000001fdc4f7d10] [c00000000035f338] do_execveat_common.isra.31+0x658/0x890
>>>> [    9.422926] [c000001fdc4f7df0] [c00000000035f980] SyS_execve+0x40/0x50
>>>> [    9.423588] [c000001fdc4f7e30] [c00000000000b220] system_call+0x58/0x6c
>>>>
>>>> which is getting hit after adding some more debug.
>>>
>>> Voila! So your binary simply overrides brk by elf segments. That sounds
>>> like the exactly the thing that the patch is supposed to protect from.
>>> Why this is the case I dunno. It is just clear that either brk or
>>> elf base are not put to the proper place. Something to get fixed. You
>>> are probably just lucky that brk allocations do not spil over to elf
>>> mappings.
>>
>> It is something to get fixed, but we can't retrospectively fix the
>> existing binaries sitting on peoples' systems.
> 
> Yeah. Can we identify those somehow? Are they something people can
> easily come across?
> 
>> Possibly powerpc arch code is doing something with the mmap layout or
>> something else that is confusing the ELF loader, in which case we should
>> fix that.
> 
> Yes this definitely should be fixed. How can elf loader completely
> overlap brk mapping?
> 
>> But if not then the only solution is for the ELF loader to be more
>> tolerant of this situation.
>>
>> So for 4.16 this patch either needs to be dropped, or reworked such that
>> powerpc can opt out of it.
> 
> Yeah, let's hold on merging this until we understand what the heck is
> going on here. If this turnes to be unfixable I will think of a way for
> ppc to opt out.
> 
> Anshuman, could you try to run
> sed 's@^@@' /proc/self/smaps
> on a system with MAP_FIXED_NOREPLACE reverted?
> 

After reverting the following commits from mmotm-2018-01-25-16-20 tag.

67caea694ba5965a52a61fdad495d847f03c4025 ("mm-introduce-map_fixed_safe-fix")
64da2e0c134ecf3936a4c36b949bcf2cdc98977e ("fs-elf-drop-map_fixed-usage-from-elf_map-fix-fix")
645983ab6ca7fd644f52b4c55462b91940012595 ("mm: don't use the same value for MAP_FIXED_NOREPLACE and MAP_SYNC")
d77bab291ac435aab91fa214b85efa74a26c9c22 ("fs-elf-drop-map_fixed-usage-from-elf_map-checkpatch-fixes")
a75c5f92d9ecb21d3299cc7db48e401cbf335c34 ("fs, elf: drop MAP_FIXED usage from elf_map")
00906d029ffe515221e3939b222c237026af2903 ("mm: introduce MAP_FIXED_NOREPLACE")

$sed 's@^@@' /proc/self/smaps
-------------------------------------------
10000000-10020000 r-xp 00000000 fd:00 10558                              /usr/bin/sed
Size:                128 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                 128 kB
Pss:                 128 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:       128 kB
Private_Dirty:         0 kB
Referenced:          128 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:              128 kB
VmFlags: rd ex mr mw me dw 
10020000-10030000 r--p 00010000 fd:00 10558                              /usr/bin/sed
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd mr mw me dw ac 
10030000-10040000 rw-p 00020000 fd:00 10558                              /usr/bin/sed
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd wr mr mw me dw ac 
2cbb0000-2cbe0000 rw-p 00000000 00:00 0                                  [heap]
Size:                192 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd wr mr mw me ac 
7fff7f9c0000-7fff7f9e0000 rw-p 00000000 00:00 0 
Size:                128 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                 128 kB
Pss:                 128 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:       128 kB
Referenced:          128 kB
Anonymous:           128 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:              128 kB
VmFlags: rd wr mr mw me ac 
7fff7f9e0000-7fff86280000 r--p 00000000 fd:00 33660156                   /usr/lib/locale/locale-archive
Size:             107136 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                 384 kB
Pss:                  37 kB
Shared_Clean:        384 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:          384 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               37 kB
VmFlags: rd mr mw me 
7fff86280000-7fff86290000 r-xp 00000000 fd:00 33660115                   /usr/lib64/libdl-2.17.so
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                   2 kB
Shared_Clean:         64 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:           64 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                2 kB
VmFlags: rd ex mr mw me 
7fff86290000-7fff862a0000 r--p 00000000 fd:00 33660115                   /usr/lib64/libdl-2.17.so
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd mr mw me ac 
7fff862a0000-7fff862b0000 rw-p 00010000 fd:00 33660115                   /usr/lib64/libdl-2.17.so
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd wr mr mw me ac 
7fff862b0000-7fff86300000 r-xp 00000000 fd:00 33594504                   /usr/lib64/libpcre.so.1.2.0
Size:                320 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                   2 kB
Shared_Clean:         64 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:           64 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                2 kB
VmFlags: rd ex mr mw me 
7fff86300000-7fff86310000 r--p 00040000 fd:00 33594504                   /usr/lib64/libpcre.so.1.2.0
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd mr mw me ac 
7fff86310000-7fff86320000 rw-p 00050000 fd:00 33594504                   /usr/lib64/libpcre.so.1.2.0
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd wr mr mw me ac 
7fff86320000-7fff864f0000 r-xp 00000000 fd:00 33660109                   /usr/lib64/libc-2.17.so
Size:               1856 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                1280 kB
Pss:                  45 kB
Shared_Clean:       1280 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:         1280 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               45 kB
VmFlags: rd ex mr mw me 
7fff864f0000-7fff86500000 r--p 001c0000 fd:00 33660109                   /usr/lib64/libc-2.17.so
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd mr mw me ac 
7fff86500000-7fff86510000 rw-p 001d0000 fd:00 33660109                   /usr/lib64/libc-2.17.so
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd wr mr mw me ac 
7fff86510000-7fff86540000 r-xp 00000000 fd:00 33594516                   /usr/lib64/libselinux.so.1
Size:                192 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                 192 kB
Pss:                   8 kB
Shared_Clean:        192 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:          192 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                8 kB
VmFlags: rd ex mr mw me 
7fff86540000-7fff86550000 r--p 00020000 fd:00 33594516                   /usr/lib64/libselinux.so.1
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd mr mw me ac 
7fff86550000-7fff86560000 rw-p 00030000 fd:00 33594516                   /usr/lib64/libselinux.so.1
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd wr mr mw me ac 
7fff86560000-7fff86570000 r--s 00000000 fd:00 67194934                   /usr/lib64/gconv/gconv-modules.cache
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  12 kB
Shared_Clean:         64 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:           64 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               12 kB
VmFlags: rd mr me ms 
7fff86570000-7fff86590000 r-xp 00000000 00:00 0                          [vdso]
Size:                128 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                   1 kB
Shared_Clean:         64 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:           64 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                1 kB
VmFlags: rd ex mr mw me de 
7fff86590000-7fff865c0000 r-xp 00000000 fd:00 33660102                   /usr/lib64/ld-2.17.so
Size:                192 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                 192 kB
Pss:                   6 kB
Shared_Clean:        192 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:          192 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                6 kB
VmFlags: rd ex mr mw me dw 
7fff865c0000-7fff865d0000 r--p 00020000 fd:00 33660102                   /usr/lib64/ld-2.17.so
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd mr mw me dw ac 
7fff865d0000-7fff865e0000 rw-p 00030000 fd:00 33660102                   /usr/lib64/ld-2.17.so
Size:                 64 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd wr mr mw me dw ac 
7fffd27a0000-7fffd27d0000 rw-p 00000000 00:00 0                          [stack]
Size:                192 kB
KernelPageSize:       64 kB
MMUPageSize:          64 kB
Rss:                  64 kB
Pss:                  64 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        64 kB
Referenced:           64 kB
Anonymous:            64 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:               64 kB
VmFlags: rd wr mr mw me gd ac 

--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-31  5:05                                                   ` Anshuman Khandual
@ 2018-01-31 13:19                                                     ` Michal Hocko
  -1 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-31 13:19 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On Wed 31-01-18 10:35:38, Anshuman Khandual wrote:
> On 01/30/2018 03:12 PM, Michal Hocko wrote:
[...]
> > Anshuman, could you try to run
> > sed 's@^@@' /proc/self/smaps
> > on a system with MAP_FIXED_NOREPLACE reverted?
> > 
> 
> After reverting the following commits from mmotm-2018-01-25-16-20 tag.
> 
> 67caea694ba5965a52a61fdad495d847f03c4025 ("mm-introduce-map_fixed_safe-fix")
> 64da2e0c134ecf3936a4c36b949bcf2cdc98977e ("fs-elf-drop-map_fixed-usage-from-elf_map-fix-fix")
> 645983ab6ca7fd644f52b4c55462b91940012595 ("mm: don't use the same value for MAP_FIXED_NOREPLACE and MAP_SYNC")
> d77bab291ac435aab91fa214b85efa74a26c9c22 ("fs-elf-drop-map_fixed-usage-from-elf_map-checkpatch-fixes")
> a75c5f92d9ecb21d3299cc7db48e401cbf335c34 ("fs, elf: drop MAP_FIXED usage from elf_map")
> 00906d029ffe515221e3939b222c237026af2903 ("mm: introduce MAP_FIXED_NOREPLACE")
> 
> $sed 's@^@@' /proc/self/smaps

Interesting

> -------------------------------------------
> 10000000-10020000 r-xp 00000000 fd:00 10558                              /usr/bin/sed
> 10020000-10030000 r--p 00010000 fd:00 10558                              /usr/bin/sed
> 10030000-10040000 rw-p 00020000 fd:00 10558                              /usr/bin/sed
> 2cbb0000-2cbe0000 rw-p 00000000 00:00 0                                  [heap]

We still have a brk and at a different offset. Could you confirm that we
still try to map previous brk at the clashing address 0x10030000?

> 7fff7f9c0000-7fff7f9e0000 rw-p 00000000 00:00 0 
> 7fff7f9e0000-7fff86280000 r--p 00000000 fd:00 33660156                   /usr/lib/locale/locale-archive
> 7fff86280000-7fff86290000 r-xp 00000000 fd:00 33660115                   /usr/lib64/libdl-2.17.so
> 7fff86290000-7fff862a0000 r--p 00000000 fd:00 33660115                   /usr/lib64/libdl-2.17.so
> 7fff862a0000-7fff862b0000 rw-p 00010000 fd:00 33660115                   /usr/lib64/libdl-2.17.so
> 7fff862b0000-7fff86300000 r-xp 00000000 fd:00 33594504                   /usr/lib64/libpcre.so.1.2.0
> 7fff86300000-7fff86310000 r--p 00040000 fd:00 33594504                   /usr/lib64/libpcre.so.1.2.0
> 7fff86310000-7fff86320000 rw-p 00050000 fd:00 33594504                   /usr/lib64/libpcre.so.1.2.0
> 7fff86320000-7fff864f0000 r-xp 00000000 fd:00 33660109                   /usr/lib64/libc-2.17.so
> 7fff864f0000-7fff86500000 r--p 001c0000 fd:00 33660109                   /usr/lib64/libc-2.17.so
> 7fff86500000-7fff86510000 rw-p 001d0000 fd:00 33660109                   /usr/lib64/libc-2.17.so
> 7fff86510000-7fff86540000 r-xp 00000000 fd:00 33594516                   /usr/lib64/libselinux.so.1
> 7fff86540000-7fff86550000 r--p 00020000 fd:00 33594516                   /usr/lib64/libselinux.so.1
> 7fff86550000-7fff86560000 rw-p 00030000 fd:00 33594516                   /usr/lib64/libselinux.so.1
> 7fff86560000-7fff86570000 r--s 00000000 fd:00 67194934                   /usr/lib64/gconv/gconv-modules.cache
> 7fff86570000-7fff86590000 r-xp 00000000 00:00 0                          [vdso]
> 7fff86590000-7fff865c0000 r-xp 00000000 fd:00 33660102                   /usr/lib64/ld-2.17.so
> 7fff865c0000-7fff865d0000 r--p 00020000 fd:00 33660102                   /usr/lib64/ld-2.17.so
> 7fff865d0000-7fff865e0000 rw-p 00030000 fd:00 33660102                   /usr/lib64/ld-2.17.so
> 7fffd27a0000-7fffd27d0000 rw-p 00000000 00:00 0                          [stack]

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-01-31 13:19                                                     ` Michal Hocko
  0 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-01-31 13:19 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On Wed 31-01-18 10:35:38, Anshuman Khandual wrote:
> On 01/30/2018 03:12 PM, Michal Hocko wrote:
[...]
> > Anshuman, could you try to run
> > sed 's@^@@' /proc/self/smaps
> > on a system with MAP_FIXED_NOREPLACE reverted?
> > 
> 
> After reverting the following commits from mmotm-2018-01-25-16-20 tag.
> 
> 67caea694ba5965a52a61fdad495d847f03c4025 ("mm-introduce-map_fixed_safe-fix")
> 64da2e0c134ecf3936a4c36b949bcf2cdc98977e ("fs-elf-drop-map_fixed-usage-from-elf_map-fix-fix")
> 645983ab6ca7fd644f52b4c55462b91940012595 ("mm: don't use the same value for MAP_FIXED_NOREPLACE and MAP_SYNC")
> d77bab291ac435aab91fa214b85efa74a26c9c22 ("fs-elf-drop-map_fixed-usage-from-elf_map-checkpatch-fixes")
> a75c5f92d9ecb21d3299cc7db48e401cbf335c34 ("fs, elf: drop MAP_FIXED usage from elf_map")
> 00906d029ffe515221e3939b222c237026af2903 ("mm: introduce MAP_FIXED_NOREPLACE")
> 
> $sed 's@^@@' /proc/self/smaps

Interesting

> -------------------------------------------
> 10000000-10020000 r-xp 00000000 fd:00 10558                              /usr/bin/sed
> 10020000-10030000 r--p 00010000 fd:00 10558                              /usr/bin/sed
> 10030000-10040000 rw-p 00020000 fd:00 10558                              /usr/bin/sed
> 2cbb0000-2cbe0000 rw-p 00000000 00:00 0                                  [heap]

We still have a brk and at a different offset. Could you confirm that we
still try to map previous brk at the clashing address 0x10030000?

> 7fff7f9c0000-7fff7f9e0000 rw-p 00000000 00:00 0 
> 7fff7f9e0000-7fff86280000 r--p 00000000 fd:00 33660156                   /usr/lib/locale/locale-archive
> 7fff86280000-7fff86290000 r-xp 00000000 fd:00 33660115                   /usr/lib64/libdl-2.17.so
> 7fff86290000-7fff862a0000 r--p 00000000 fd:00 33660115                   /usr/lib64/libdl-2.17.so
> 7fff862a0000-7fff862b0000 rw-p 00010000 fd:00 33660115                   /usr/lib64/libdl-2.17.so
> 7fff862b0000-7fff86300000 r-xp 00000000 fd:00 33594504                   /usr/lib64/libpcre.so.1.2.0
> 7fff86300000-7fff86310000 r--p 00040000 fd:00 33594504                   /usr/lib64/libpcre.so.1.2.0
> 7fff86310000-7fff86320000 rw-p 00050000 fd:00 33594504                   /usr/lib64/libpcre.so.1.2.0
> 7fff86320000-7fff864f0000 r-xp 00000000 fd:00 33660109                   /usr/lib64/libc-2.17.so
> 7fff864f0000-7fff86500000 r--p 001c0000 fd:00 33660109                   /usr/lib64/libc-2.17.so
> 7fff86500000-7fff86510000 rw-p 001d0000 fd:00 33660109                   /usr/lib64/libc-2.17.so
> 7fff86510000-7fff86540000 r-xp 00000000 fd:00 33594516                   /usr/lib64/libselinux.so.1
> 7fff86540000-7fff86550000 r--p 00020000 fd:00 33594516                   /usr/lib64/libselinux.so.1
> 7fff86550000-7fff86560000 rw-p 00030000 fd:00 33594516                   /usr/lib64/libselinux.so.1
> 7fff86560000-7fff86570000 r--s 00000000 fd:00 67194934                   /usr/lib64/gconv/gconv-modules.cache
> 7fff86570000-7fff86590000 r-xp 00000000 00:00 0                          [vdso]
> 7fff86590000-7fff865c0000 r-xp 00000000 fd:00 33660102                   /usr/lib64/ld-2.17.so
> 7fff865c0000-7fff865d0000 r--p 00020000 fd:00 33660102                   /usr/lib64/ld-2.17.so
> 7fff865d0000-7fff865e0000 rw-p 00030000 fd:00 33660102                   /usr/lib64/ld-2.17.so
> 7fffd27a0000-7fffd27d0000 rw-p 00000000 00:00 0                          [stack]

-- 
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-01-31 13:19                                                     ` Michal Hocko
@ 2018-02-01  3:13                                                       ` Anshuman Khandual
  -1 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-02-01  3:13 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On 01/31/2018 06:49 PM, Michal Hocko wrote:
> On Wed 31-01-18 10:35:38, Anshuman Khandual wrote:
>> On 01/30/2018 03:12 PM, Michal Hocko wrote:
> [...]
>>> Anshuman, could you try to run
>>> sed 's@^@@' /proc/self/smaps
>>> on a system with MAP_FIXED_NOREPLACE reverted?
>>>
>> After reverting the following commits from mmotm-2018-01-25-16-20 tag.
>>
>> 67caea694ba5965a52a61fdad495d847f03c4025 ("mm-introduce-map_fixed_safe-fix")
>> 64da2e0c134ecf3936a4c36b949bcf2cdc98977e ("fs-elf-drop-map_fixed-usage-from-elf_map-fix-fix")
>> 645983ab6ca7fd644f52b4c55462b91940012595 ("mm: don't use the same value for MAP_FIXED_NOREPLACE and MAP_SYNC")
>> d77bab291ac435aab91fa214b85efa74a26c9c22 ("fs-elf-drop-map_fixed-usage-from-elf_map-checkpatch-fixes")
>> a75c5f92d9ecb21d3299cc7db48e401cbf335c34 ("fs, elf: drop MAP_FIXED usage from elf_map")
>> 00906d029ffe515221e3939b222c237026af2903 ("mm: introduce MAP_FIXED_NOREPLACE")
>>
>> $sed 's@^@@' /proc/self/smaps
> Interesting
> 
>> -------------------------------------------
>> 10000000-10020000 r-xp 00000000 fd:00 10558                              /usr/bin/sed
>> 10020000-10030000 r--p 00010000 fd:00 10558                              /usr/bin/sed
>> 10030000-10040000 rw-p 00020000 fd:00 10558                              /usr/bin/sed
>> 2cbb0000-2cbe0000 rw-p 00000000 00:00 0                                  [heap]
> We still have a brk and at a different offset. Could you confirm that we
> still try to map previous brk at the clashing address 0x10030000?

yes.

[    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)

$dmesg | grep elf_brk
[    9.571192] elf_brk 10030328 elf_bss 10030000

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.

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-02-01  3:13                                                       ` Anshuman Khandual
  0 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-02-01  3:13 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On 01/31/2018 06:49 PM, Michal Hocko wrote:
> On Wed 31-01-18 10:35:38, Anshuman Khandual wrote:
>> On 01/30/2018 03:12 PM, Michal Hocko wrote:
> [...]
>>> Anshuman, could you try to run
>>> sed 's@^@@' /proc/self/smaps
>>> on a system with MAP_FIXED_NOREPLACE reverted?
>>>
>> After reverting the following commits from mmotm-2018-01-25-16-20 tag.
>>
>> 67caea694ba5965a52a61fdad495d847f03c4025 ("mm-introduce-map_fixed_safe-fix")
>> 64da2e0c134ecf3936a4c36b949bcf2cdc98977e ("fs-elf-drop-map_fixed-usage-from-elf_map-fix-fix")
>> 645983ab6ca7fd644f52b4c55462b91940012595 ("mm: don't use the same value for MAP_FIXED_NOREPLACE and MAP_SYNC")
>> d77bab291ac435aab91fa214b85efa74a26c9c22 ("fs-elf-drop-map_fixed-usage-from-elf_map-checkpatch-fixes")
>> a75c5f92d9ecb21d3299cc7db48e401cbf335c34 ("fs, elf: drop MAP_FIXED usage from elf_map")
>> 00906d029ffe515221e3939b222c237026af2903 ("mm: introduce MAP_FIXED_NOREPLACE")
>>
>> $sed 's@^@@' /proc/self/smaps
> Interesting
> 
>> -------------------------------------------
>> 10000000-10020000 r-xp 00000000 fd:00 10558                              /usr/bin/sed
>> 10020000-10030000 r--p 00010000 fd:00 10558                              /usr/bin/sed
>> 10030000-10040000 rw-p 00020000 fd:00 10558                              /usr/bin/sed
>> 2cbb0000-2cbe0000 rw-p 00000000 00:00 0                                  [heap]
> We still have a brk and at a different offset. Could you confirm that we
> still try to map previous brk at the clashing address 0x10030000?

yes.

[    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)

$dmesg | grep elf_brk
[    9.571192] elf_brk 10030328 elf_bss 10030000

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.

--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-02-01  3:13                                                       ` Anshuman Khandual
@ 2018-02-01 13:10                                                         ` Michal Hocko
  -1 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-02-01 13:10 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie, Kees Cook,
	Linus Torvalds

[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

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-02-01 13:10                                                         ` Michal Hocko
  0 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-02-01 13:10 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie, Kees Cook,
	Linus Torvalds

[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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-02-01 13:10                                                         ` Michal Hocko
@ 2018-02-01 13:40                                                           ` Michal Hocko
  -1 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-02-01 13:40 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie, Kees Cook,
	Linus Torvalds

On Thu 01-02-18 14:10:07, Michal Hocko wrote:
> [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.

Thanks a lot to Michael Matz for his background. He has pointed me to
the following two segments from your binary[1]
  LOAD           0x0000000000000000 0x0000000010000000 0x0000000010000000
                 0x0000000000013a8c 0x0000000000013a8c  R E    10000
  LOAD           0x000000000001fd40 0x000000001002fd40 0x000000001002fd40
                 0x00000000000002c0 0x00000000000005e8  RW     10000
  LOAD           0x0000000000020328 0x0000000010030328 0x0000000010030328
                 0x0000000000000384 0x00000000000094a0  RW     10000

That binary has two RW LOAD segments, the first crosses a page border
into the second
0x1002fd40 (LOAD2-vaddr) + 0x5e8 (LOAD2-memlen) == 0x10030328 (LOAD3-vaddr)

He says
: This is actually an artifact of RELRO machinism.  The first RW mapping
: will be remapped as RO after relocations are applied (to increase
: security).
: Well, to be honest, normal relro binaries also don't have more than
: two LOAD segments, so whatever RHEL did to their compilation options,
: it's something in addition to just relro (which can be detected by
: having a GNU_RELRO program header)
: But it definitely has something to do with relro, it's just not the
: whole story yet.

I am still trying to wrap my head around all this, but it smells rather
dubious to map different segments over the same page. Is this something
that might happen widely and therefore MAP_FIXED_NOREPLACE is a no-go
when loading ELF segments? Or is this a special case we can detect?

Or am I completely off?

[1] http://lkml.kernel.org/r/96458c0a-e273-3fb9-a33b-f6f2d536f90b%40linux.vnet.ibm.com

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-02-01 13:40                                                           ` Michal Hocko
  0 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-02-01 13:40 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie, Kees Cook,
	Linus Torvalds

On Thu 01-02-18 14:10:07, Michal Hocko wrote:
> [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.

Thanks a lot to Michael Matz for his background. He has pointed me to
the following two segments from your binary[1]
  LOAD           0x0000000000000000 0x0000000010000000 0x0000000010000000
                 0x0000000000013a8c 0x0000000000013a8c  R E    10000
  LOAD           0x000000000001fd40 0x000000001002fd40 0x000000001002fd40
                 0x00000000000002c0 0x00000000000005e8  RW     10000
  LOAD           0x0000000000020328 0x0000000010030328 0x0000000010030328
                 0x0000000000000384 0x00000000000094a0  RW     10000

That binary has two RW LOAD segments, the first crosses a page border
into the second
0x1002fd40 (LOAD2-vaddr) + 0x5e8 (LOAD2-memlen) == 0x10030328 (LOAD3-vaddr)

He says
: This is actually an artifact of RELRO machinism.  The first RW mapping
: will be remapped as RO after relocations are applied (to increase
: security).
: Well, to be honest, normal relro binaries also don't have more than
: two LOAD segments, so whatever RHEL did to their compilation options,
: it's something in addition to just relro (which can be detected by
: having a GNU_RELRO program header)
: But it definitely has something to do with relro, it's just not the
: whole story yet.

I am still trying to wrap my head around all this, but it smells rather
dubious to map different segments over the same page. Is this something
that might happen widely and therefore MAP_FIXED_NOREPLACE is a no-go
when loading ELF segments? Or is this a special case we can detect?

Or am I completely off?

[1] http://lkml.kernel.org/r/96458c0a-e273-3fb9-a33b-f6f2d536f90b%40linux.vnet.ibm.com

-- 
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-02-01  3:13                                                       ` Anshuman Khandual
@ 2018-02-01 13:48                                                         ` Michal Hocko
  -1 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-02-01 13:48 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On Thu 01-02-18 08:43:34, Anshuman Khandual wrote:
[...]
> $dmesg | grep elf_brk
> [    9.571192] elf_brk 10030328 elf_bss 10030000
> 
> 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);
> 
> 
> ---------------------

Just a blind shot... Does the following make any difference?
---
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 021fe78998ea..04b24d00c911 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -895,7 +895,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
 	   the correct location in memory. */
 	for(i = 0, elf_ppnt = elf_phdata;
 	    i < loc->elf_ex.e_phnum; i++, elf_ppnt++) {
-		int elf_prot = 0, elf_flags;
+		int elf_prot = 0, elf_flags, elf_fixed = MAP_FIXED_NOREPLACE;
 		unsigned long k, vaddr;
 		unsigned long total_size = 0;
 
@@ -927,6 +927,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
 					 */
 				}
 			}
+			elf_fixed = MAP_FIXED;
 		}
 
 		if (elf_ppnt->p_flags & PF_R)
@@ -944,7 +945,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_NOREPLACE;
+			elf_flags |= elf_fixed;
 		} else if (loc->elf_ex.e_type == ET_DYN) {
 			/*
 			 * This logic is run once for the first LOAD Program
@@ -980,7 +981,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
 				load_bias = ELF_ET_DYN_BASE;
 				if (current->flags & PF_RANDOMIZE)
 					load_bias += arch_mmap_rnd();
-				elf_flags |= MAP_FIXED_NOREPLACE;
+				elf_flags |= elf_fixed;
 			} else
 				load_bias = 0;
 

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply related	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-02-01 13:48                                                         ` Michal Hocko
  0 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-02-01 13:48 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On Thu 01-02-18 08:43:34, Anshuman Khandual wrote:
[...]
> $dmesg | grep elf_brk
> [    9.571192] elf_brk 10030328 elf_bss 10030000
> 
> 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);
> 
> 
> ---------------------

Just a blind shot... Does the following make any difference?
---
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 021fe78998ea..04b24d00c911 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -895,7 +895,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
 	   the correct location in memory. */
 	for(i = 0, elf_ppnt = elf_phdata;
 	    i < loc->elf_ex.e_phnum; i++, elf_ppnt++) {
-		int elf_prot = 0, elf_flags;
+		int elf_prot = 0, elf_flags, elf_fixed = MAP_FIXED_NOREPLACE;
 		unsigned long k, vaddr;
 		unsigned long total_size = 0;
 
@@ -927,6 +927,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
 					 */
 				}
 			}
+			elf_fixed = MAP_FIXED;
 		}
 
 		if (elf_ppnt->p_flags & PF_R)
@@ -944,7 +945,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_NOREPLACE;
+			elf_flags |= elf_fixed;
 		} else if (loc->elf_ex.e_type == ET_DYN) {
 			/*
 			 * This logic is run once for the first LOAD Program
@@ -980,7 +981,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
 				load_bias = ELF_ET_DYN_BASE;
 				if (current->flags & PF_RANDOMIZE)
 					load_bias += arch_mmap_rnd();
-				elf_flags |= MAP_FIXED_NOREPLACE;
+				elf_flags |= elf_fixed;
 			} else
 				load_bias = 0;
 

-- 
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>

^ permalink raw reply related	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-02-01 13:40                                                           ` Michal Hocko
@ 2018-02-01 20:55                                                             ` Kees Cook
  -1 siblings, 0 replies; 82+ messages in thread
From: Kees Cook @ 2018-02-01 20:55 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Anshuman Khandual, Michael Ellerman, akpm, mm-commits, LKML,
	Linux-MM, linux-fsdevel, Linux-Next, Stephen Rothwell,
	Mark Brown, Linus Torvalds

On Fri, Feb 2, 2018 at 12:40 AM, Michal Hocko <mhocko@kernel.org> wrote:
> On Thu 01-02-18 14:10:07, Michal Hocko wrote:
> Thanks a lot to Michael Matz for his background. He has pointed me to
> the following two segments from your binary[1]
>   LOAD           0x0000000000000000 0x0000000010000000 0x0000000010000000
>                  0x0000000000013a8c 0x0000000000013a8c  R E    10000
>   LOAD           0x000000000001fd40 0x000000001002fd40 0x000000001002fd40
>                  0x00000000000002c0 0x00000000000005e8  RW     10000
>   LOAD           0x0000000000020328 0x0000000010030328 0x0000000010030328
>                  0x0000000000000384 0x00000000000094a0  RW     10000
>
> That binary has two RW LOAD segments, the first crosses a page border
> into the second
> 0x1002fd40 (LOAD2-vaddr) + 0x5e8 (LOAD2-memlen) == 0x10030328 (LOAD3-vaddr)
>
> He says
> : This is actually an artifact of RELRO machinism.  The first RW mapping
> : will be remapped as RO after relocations are applied (to increase
> : security).
> : Well, to be honest, normal relro binaries also don't have more than
> : two LOAD segments, so whatever RHEL did to their compilation options,
> : it's something in addition to just relro (which can be detected by
> : having a GNU_RELRO program header)
> : But it definitely has something to do with relro, it's just not the
> : whole story yet.
>
> I am still trying to wrap my head around all this, but it smells rather
> dubious to map different segments over the same page. Is this something
> that might happen widely and therefore MAP_FIXED_NOREPLACE is a no-go
> when loading ELF segments? Or is this a special case we can detect?

Eww. FWIW, I would expect that to be rare and detectable.

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-02-01 20:55                                                             ` Kees Cook
  0 siblings, 0 replies; 82+ messages in thread
From: Kees Cook @ 2018-02-01 20:55 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Anshuman Khandual, Michael Ellerman, akpm, mm-commits, LKML,
	Linux-MM, linux-fsdevel, Linux-Next, Stephen Rothwell,
	Mark Brown, Linus Torvalds

On Fri, Feb 2, 2018 at 12:40 AM, Michal Hocko <mhocko@kernel.org> wrote:
> On Thu 01-02-18 14:10:07, Michal Hocko wrote:
> Thanks a lot to Michael Matz for his background. He has pointed me to
> the following two segments from your binary[1]
>   LOAD           0x0000000000000000 0x0000000010000000 0x0000000010000000
>                  0x0000000000013a8c 0x0000000000013a8c  R E    10000
>   LOAD           0x000000000001fd40 0x000000001002fd40 0x000000001002fd40
>                  0x00000000000002c0 0x00000000000005e8  RW     10000
>   LOAD           0x0000000000020328 0x0000000010030328 0x0000000010030328
>                  0x0000000000000384 0x00000000000094a0  RW     10000
>
> That binary has two RW LOAD segments, the first crosses a page border
> into the second
> 0x1002fd40 (LOAD2-vaddr) + 0x5e8 (LOAD2-memlen) == 0x10030328 (LOAD3-vaddr)
>
> He says
> : This is actually an artifact of RELRO machinism.  The first RW mapping
> : will be remapped as RO after relocations are applied (to increase
> : security).
> : Well, to be honest, normal relro binaries also don't have more than
> : two LOAD segments, so whatever RHEL did to their compilation options,
> : it's something in addition to just relro (which can be detected by
> : having a GNU_RELRO program header)
> : But it definitely has something to do with relro, it's just not the
> : whole story yet.
>
> I am still trying to wrap my head around all this, but it smells rather
> dubious to map different segments over the same page. Is this something
> that might happen widely and therefore MAP_FIXED_NOREPLACE is a no-go
> when loading ELF segments? Or is this a special case we can detect?

Eww. FWIW, I would expect that to be rare and detectable.

-Kees

-- 
Kees Cook
Pixel Security

--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-02-01 13:48                                                         ` Michal Hocko
@ 2018-02-01 21:06                                                           ` Kees Cook
  -1 siblings, 0 replies; 82+ messages in thread
From: Kees Cook @ 2018-02-01 21:06 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Anshuman Khandual, Michael Ellerman, akpm, mm-commits, LKML,
	Linux-MM, linux-fsdevel, Linux-Next, Stephen Rothwell,
	Mark Brown

On Fri, Feb 2, 2018 at 12:48 AM, Michal Hocko <mhocko@kernel.org> wrote:
> On Thu 01-02-18 08:43:34, Anshuman Khandual wrote:
> [...]
>> $dmesg | grep elf_brk
>> [    9.571192] elf_brk 10030328 elf_bss 10030000
>>
>> 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);
>>
>>
>> ---------------------
>
> Just a blind shot... Does the following make any difference?
> ---
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 021fe78998ea..04b24d00c911 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -895,7 +895,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>            the correct location in memory. */
>         for(i = 0, elf_ppnt = elf_phdata;
>             i < loc->elf_ex.e_phnum; i++, elf_ppnt++) {
> -               int elf_prot = 0, elf_flags;
> +               int elf_prot = 0, elf_flags, elf_fixed = MAP_FIXED_NOREPLACE;
>                 unsigned long k, vaddr;
>                 unsigned long total_size = 0;
>
> @@ -927,6 +927,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>                                          */
>                                 }
>                         }
> +                       elf_fixed = MAP_FIXED;
>                 }
>
>                 if (elf_ppnt->p_flags & PF_R)
> @@ -944,7 +945,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_NOREPLACE;
> +                       elf_flags |= elf_fixed;
>                 } else if (loc->elf_ex.e_type == ET_DYN) {
>                         /*
>                          * This logic is run once for the first LOAD Program
> @@ -980,7 +981,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>                                 load_bias = ELF_ET_DYN_BASE;
>                                 if (current->flags & PF_RANDOMIZE)
>                                         load_bias += arch_mmap_rnd();
> -                               elf_flags |= MAP_FIXED_NOREPLACE;
> +                               elf_flags |= elf_fixed;
>                         } else
>                                 load_bias = 0;

If I'm reading this patch correctly, the intention is to allow LOADs
after brk-expansion to collide with the prior LOAD? (This patch will
need more comments for our future sanity.) I think this makes sense,
though it might be nice to be sure we're overlapping only with the
prior LOAD (and nothing else), but it's not clear to me the best way
to accomplish that here. Even without that extra check, I think this
is a net benefit (i.e. gain MAP_FIXED_NOREPLACE without breaking
page-crossing LOADs).

Actually, maybe the second LOAD could be page-aligned first, so it
doesn't collide with the prior LOAD, and it could keep
MAP_FIXED_NOREPLACE? I'll have more time to study this on Monday...

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-02-01 21:06                                                           ` Kees Cook
  0 siblings, 0 replies; 82+ messages in thread
From: Kees Cook @ 2018-02-01 21:06 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Anshuman Khandual, Michael Ellerman, akpm, mm-commits, LKML,
	Linux-MM, linux-fsdevel, Linux-Next, Stephen Rothwell,
	Mark Brown

On Fri, Feb 2, 2018 at 12:48 AM, Michal Hocko <mhocko@kernel.org> wrote:
> On Thu 01-02-18 08:43:34, Anshuman Khandual wrote:
> [...]
>> $dmesg | grep elf_brk
>> [    9.571192] elf_brk 10030328 elf_bss 10030000
>>
>> 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);
>>
>>
>> ---------------------
>
> Just a blind shot... Does the following make any difference?
> ---
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 021fe78998ea..04b24d00c911 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -895,7 +895,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>            the correct location in memory. */
>         for(i = 0, elf_ppnt = elf_phdata;
>             i < loc->elf_ex.e_phnum; i++, elf_ppnt++) {
> -               int elf_prot = 0, elf_flags;
> +               int elf_prot = 0, elf_flags, elf_fixed = MAP_FIXED_NOREPLACE;
>                 unsigned long k, vaddr;
>                 unsigned long total_size = 0;
>
> @@ -927,6 +927,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>                                          */
>                                 }
>                         }
> +                       elf_fixed = MAP_FIXED;
>                 }
>
>                 if (elf_ppnt->p_flags & PF_R)
> @@ -944,7 +945,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_NOREPLACE;
> +                       elf_flags |= elf_fixed;
>                 } else if (loc->elf_ex.e_type == ET_DYN) {
>                         /*
>                          * This logic is run once for the first LOAD Program
> @@ -980,7 +981,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>                                 load_bias = ELF_ET_DYN_BASE;
>                                 if (current->flags & PF_RANDOMIZE)
>                                         load_bias += arch_mmap_rnd();
> -                               elf_flags |= MAP_FIXED_NOREPLACE;
> +                               elf_flags |= elf_fixed;
>                         } else
>                                 load_bias = 0;

If I'm reading this patch correctly, the intention is to allow LOADs
after brk-expansion to collide with the prior LOAD? (This patch will
need more comments for our future sanity.) I think this makes sense,
though it might be nice to be sure we're overlapping only with the
prior LOAD (and nothing else), but it's not clear to me the best way
to accomplish that here. Even without that extra check, I think this
is a net benefit (i.e. gain MAP_FIXED_NOREPLACE without breaking
page-crossing LOADs).

Actually, maybe the second LOAD could be page-aligned first, so it
doesn't collide with the prior LOAD, and it could keep
MAP_FIXED_NOREPLACE? I'll have more time to study this on Monday...

-Kees

-- 
Kees Cook
Pixel Security

--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-02-01 13:48                                                         ` Michal Hocko
@ 2018-02-12 14:48                                                           ` Michal Hocko
  -1 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-02-12 14:48 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

Did you have any chance to test the following hack, Anshuman?

On Thu 01-02-18 14:48:29, Michal Hocko wrote:
[...]
> Just a blind shot... Does the following make any difference?
> ---
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 021fe78998ea..04b24d00c911 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -895,7 +895,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>  	   the correct location in memory. */
>  	for(i = 0, elf_ppnt = elf_phdata;
>  	    i < loc->elf_ex.e_phnum; i++, elf_ppnt++) {
> -		int elf_prot = 0, elf_flags;
> +		int elf_prot = 0, elf_flags, elf_fixed = MAP_FIXED_NOREPLACE;
>  		unsigned long k, vaddr;
>  		unsigned long total_size = 0;
>  
> @@ -927,6 +927,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>  					 */
>  				}
>  			}
> +			elf_fixed = MAP_FIXED;
>  		}
>  
>  		if (elf_ppnt->p_flags & PF_R)
> @@ -944,7 +945,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_NOREPLACE;
> +			elf_flags |= elf_fixed;
>  		} else if (loc->elf_ex.e_type == ET_DYN) {
>  			/*
>  			 * This logic is run once for the first LOAD Program
> @@ -980,7 +981,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>  				load_bias = ELF_ET_DYN_BASE;
>  				if (current->flags & PF_RANDOMIZE)
>  					load_bias += arch_mmap_rnd();
> -				elf_flags |= MAP_FIXED_NOREPLACE;
> +				elf_flags |= elf_fixed;
>  			} else
>  				load_bias = 0;
>  
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-02-12 14:48                                                           ` Michal Hocko
  0 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-02-12 14:48 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

Did you have any chance to test the following hack, Anshuman?

On Thu 01-02-18 14:48:29, Michal Hocko wrote:
[...]
> Just a blind shot... Does the following make any difference?
> ---
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 021fe78998ea..04b24d00c911 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -895,7 +895,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>  	   the correct location in memory. */
>  	for(i = 0, elf_ppnt = elf_phdata;
>  	    i < loc->elf_ex.e_phnum; i++, elf_ppnt++) {
> -		int elf_prot = 0, elf_flags;
> +		int elf_prot = 0, elf_flags, elf_fixed = MAP_FIXED_NOREPLACE;
>  		unsigned long k, vaddr;
>  		unsigned long total_size = 0;
>  
> @@ -927,6 +927,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>  					 */
>  				}
>  			}
> +			elf_fixed = MAP_FIXED;
>  		}
>  
>  		if (elf_ppnt->p_flags & PF_R)
> @@ -944,7 +945,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_NOREPLACE;
> +			elf_flags |= elf_fixed;
>  		} else if (loc->elf_ex.e_type == ET_DYN) {
>  			/*
>  			 * This logic is run once for the first LOAD Program
> @@ -980,7 +981,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>  				load_bias = ELF_ET_DYN_BASE;
>  				if (current->flags & PF_RANDOMIZE)
>  					load_bias += arch_mmap_rnd();
> -				elf_flags |= MAP_FIXED_NOREPLACE;
> +				elf_flags |= elf_fixed;
>  			} else
>  				load_bias = 0;
>  
-- 
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-02-12 14:48                                                           ` Michal Hocko
@ 2018-02-13  1:02                                                             ` Anshuman Khandual
  -1 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-02-13  1:02 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On 02/12/2018 08:18 PM, Michal Hocko wrote:
> Did you have any chance to test the following hack, Anshuman?

The system has some issues at the moment, will get back on this.

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-02-13  1:02                                                             ` Anshuman Khandual
  0 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-02-13  1:02 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On 02/12/2018 08:18 PM, Michal Hocko wrote:
> Did you have any chance to test the following hack, Anshuman?

The system has some issues at the moment, will get back on this.

--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-02-01 13:48                                                         ` Michal Hocko
@ 2018-02-13  6:49                                                           ` Anshuman Khandual
  -1 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-02-13  6:49 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On 02/01/2018 07:18 PM, Michal Hocko wrote:
> On Thu 01-02-18 08:43:34, Anshuman Khandual wrote:
> [...]
>> $dmesg | grep elf_brk
>> [    9.571192] elf_brk 10030328 elf_bss 10030000
>>
>> 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);
>>
>>
>> ---------------------
> 
> Just a blind shot... Does the following make any difference?
> ---
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 021fe78998ea..04b24d00c911 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -895,7 +895,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>  	   the correct location in memory. */
>  	for(i = 0, elf_ppnt = elf_phdata;
>  	    i < loc->elf_ex.e_phnum; i++, elf_ppnt++) {
> -		int elf_prot = 0, elf_flags;
> +		int elf_prot = 0, elf_flags, elf_fixed = MAP_FIXED_NOREPLACE;
>  		unsigned long k, vaddr;
>  		unsigned long total_size = 0;
>  
> @@ -927,6 +927,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>  					 */
>  				}
>  			}
> +			elf_fixed = MAP_FIXED;
>  		}
>  
>  		if (elf_ppnt->p_flags & PF_R)
> @@ -944,7 +945,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_NOREPLACE;
> +			elf_flags |= elf_fixed;
>  		} else if (loc->elf_ex.e_type == ET_DYN) {
>  			/*
>  			 * This logic is run once for the first LOAD Program
> @@ -980,7 +981,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>  				load_bias = ELF_ET_DYN_BASE;
>  				if (current->flags & PF_RANDOMIZE)
>  					load_bias += arch_mmap_rnd();
> -				elf_flags |= MAP_FIXED_NOREPLACE;
> +				elf_flags |= elf_fixed;
>  			} else
>  				load_bias = 0;
>  
> 

Yeah, it does solve the problem on mmotm-2018-01-25-16-20.

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-02-13  6:49                                                           ` Anshuman Khandual
  0 siblings, 0 replies; 82+ messages in thread
From: Anshuman Khandual @ 2018-02-13  6:49 UTC (permalink / raw)
  To: Michal Hocko, Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On 02/01/2018 07:18 PM, Michal Hocko wrote:
> On Thu 01-02-18 08:43:34, Anshuman Khandual wrote:
> [...]
>> $dmesg | grep elf_brk
>> [    9.571192] elf_brk 10030328 elf_bss 10030000
>>
>> 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);
>>
>>
>> ---------------------
> 
> Just a blind shot... Does the following make any difference?
> ---
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 021fe78998ea..04b24d00c911 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -895,7 +895,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>  	   the correct location in memory. */
>  	for(i = 0, elf_ppnt = elf_phdata;
>  	    i < loc->elf_ex.e_phnum; i++, elf_ppnt++) {
> -		int elf_prot = 0, elf_flags;
> +		int elf_prot = 0, elf_flags, elf_fixed = MAP_FIXED_NOREPLACE;
>  		unsigned long k, vaddr;
>  		unsigned long total_size = 0;
>  
> @@ -927,6 +927,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>  					 */
>  				}
>  			}
> +			elf_fixed = MAP_FIXED;
>  		}
>  
>  		if (elf_ppnt->p_flags & PF_R)
> @@ -944,7 +945,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_NOREPLACE;
> +			elf_flags |= elf_fixed;
>  		} else if (loc->elf_ex.e_type == ET_DYN) {
>  			/*
>  			 * This logic is run once for the first LOAD Program
> @@ -980,7 +981,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>  				load_bias = ELF_ET_DYN_BASE;
>  				if (current->flags & PF_RANDOMIZE)
>  					load_bias += arch_mmap_rnd();
> -				elf_flags |= MAP_FIXED_NOREPLACE;
> +				elf_flags |= elf_fixed;
>  			} else
>  				load_bias = 0;
>  
> 

Yeah, it does solve the problem on mmotm-2018-01-25-16-20.

--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
  2018-02-13  6:49                                                           ` Anshuman Khandual
@ 2018-02-13 10:00                                                             ` Michal Hocko
  -1 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-02-13 10:00 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On Tue 13-02-18 12:19:18, Anshuman Khandual wrote:
> On 02/01/2018 07:18 PM, Michal Hocko wrote:
> > On Thu 01-02-18 08:43:34, Anshuman Khandual wrote:
> > [...]
> >> $dmesg | grep elf_brk
> >> [    9.571192] elf_brk 10030328 elf_bss 10030000
> >>
> >> 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);
> >>
> >>
> >> ---------------------
> > 
> > Just a blind shot... Does the following make any difference?
> > ---
> > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> > index 021fe78998ea..04b24d00c911 100644
> > --- a/fs/binfmt_elf.c
> > +++ b/fs/binfmt_elf.c
> > @@ -895,7 +895,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
> >  	   the correct location in memory. */
> >  	for(i = 0, elf_ppnt = elf_phdata;
> >  	    i < loc->elf_ex.e_phnum; i++, elf_ppnt++) {
> > -		int elf_prot = 0, elf_flags;
> > +		int elf_prot = 0, elf_flags, elf_fixed = MAP_FIXED_NOREPLACE;
> >  		unsigned long k, vaddr;
> >  		unsigned long total_size = 0;
> >  
> > @@ -927,6 +927,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
> >  					 */
> >  				}
> >  			}
> > +			elf_fixed = MAP_FIXED;
> >  		}
> >  
> >  		if (elf_ppnt->p_flags & PF_R)
> > @@ -944,7 +945,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_NOREPLACE;
> > +			elf_flags |= elf_fixed;
> >  		} else if (loc->elf_ex.e_type == ET_DYN) {
> >  			/*
> >  			 * This logic is run once for the first LOAD Program
> > @@ -980,7 +981,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
> >  				load_bias = ELF_ET_DYN_BASE;
> >  				if (current->flags & PF_RANDOMIZE)
> >  					load_bias += arch_mmap_rnd();
> > -				elf_flags |= MAP_FIXED_NOREPLACE;
> > +				elf_flags |= elf_fixed;
> >  			} else
> >  				load_bias = 0;
> >  
> > 
> 
> Yeah, it does solve the problem on mmotm-2018-01-25-16-20.

Thanks a lot for testing! I will post an RFC patch shortly.

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
@ 2018-02-13 10:00                                                             ` Michal Hocko
  0 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-02-13 10:00 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Michael Ellerman, akpm, mm-commits, linux-kernel, linux-mm,
	linux-fsdevel, linux-next, sfr, broonie

On Tue 13-02-18 12:19:18, Anshuman Khandual wrote:
> On 02/01/2018 07:18 PM, Michal Hocko wrote:
> > On Thu 01-02-18 08:43:34, Anshuman Khandual wrote:
> > [...]
> >> $dmesg | grep elf_brk
> >> [    9.571192] elf_brk 10030328 elf_bss 10030000
> >>
> >> 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);
> >>
> >>
> >> ---------------------
> > 
> > Just a blind shot... Does the following make any difference?
> > ---
> > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> > index 021fe78998ea..04b24d00c911 100644
> > --- a/fs/binfmt_elf.c
> > +++ b/fs/binfmt_elf.c
> > @@ -895,7 +895,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
> >  	   the correct location in memory. */
> >  	for(i = 0, elf_ppnt = elf_phdata;
> >  	    i < loc->elf_ex.e_phnum; i++, elf_ppnt++) {
> > -		int elf_prot = 0, elf_flags;
> > +		int elf_prot = 0, elf_flags, elf_fixed = MAP_FIXED_NOREPLACE;
> >  		unsigned long k, vaddr;
> >  		unsigned long total_size = 0;
> >  
> > @@ -927,6 +927,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
> >  					 */
> >  				}
> >  			}
> > +			elf_fixed = MAP_FIXED;
> >  		}
> >  
> >  		if (elf_ppnt->p_flags & PF_R)
> > @@ -944,7 +945,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_NOREPLACE;
> > +			elf_flags |= elf_fixed;
> >  		} else if (loc->elf_ex.e_type == ET_DYN) {
> >  			/*
> >  			 * This logic is run once for the first LOAD Program
> > @@ -980,7 +981,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
> >  				load_bias = ELF_ET_DYN_BASE;
> >  				if (current->flags & PF_RANDOMIZE)
> >  					load_bias += arch_mmap_rnd();
> > -				elf_flags |= MAP_FIXED_NOREPLACE;
> > +				elf_flags |= elf_fixed;
> >  			} else
> >  				load_bias = 0;
> >  
> > 
> 
> Yeah, it does solve the problem on mmotm-2018-01-25-16-20.

Thanks a lot for testing! I will post an RFC patch shortly.

-- 
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* [RFC PATCH] elf: enforce MAP_FIXED on overlaying elf segments (was: Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE)
  2018-02-01 20:55                                                             ` Kees Cook
  (?)
@ 2018-02-13 10:04                                                               ` Michal Hocko
  -1 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-02-13 10:04 UTC (permalink / raw)
  To: Kees Cook
  Cc: Anshuman Khandual, Michael Ellerman, akpm, mm-commits, LKML,
	Linux-MM, linux-fsdevel, Linux-Next, Stephen Rothwell,
	Mark Brown, Linus Torvalds

On Fri 02-02-18 07:55:14, Kees Cook wrote:
> On Fri, Feb 2, 2018 at 12:40 AM, Michal Hocko <mhocko@kernel.org> wrote:
> > On Thu 01-02-18 14:10:07, Michal Hocko wrote:
> > Thanks a lot to Michael Matz for his background. He has pointed me to
> > the following two segments from your binary[1]
> >   LOAD           0x0000000000000000 0x0000000010000000 0x0000000010000000
> >                  0x0000000000013a8c 0x0000000000013a8c  R E    10000
> >   LOAD           0x000000000001fd40 0x000000001002fd40 0x000000001002fd40
> >                  0x00000000000002c0 0x00000000000005e8  RW     10000
> >   LOAD           0x0000000000020328 0x0000000010030328 0x0000000010030328
> >                  0x0000000000000384 0x00000000000094a0  RW     10000
> >
> > That binary has two RW LOAD segments, the first crosses a page border
> > into the second
> > 0x1002fd40 (LOAD2-vaddr) + 0x5e8 (LOAD2-memlen) == 0x10030328 (LOAD3-vaddr)
> >
> > He says
> > : This is actually an artifact of RELRO machinism.  The first RW mapping
> > : will be remapped as RO after relocations are applied (to increase
> > : security).
> > : Well, to be honest, normal relro binaries also don't have more than
> > : two LOAD segments, so whatever RHEL did to their compilation options,
> > : it's something in addition to just relro (which can be detected by
> > : having a GNU_RELRO program header)
> > : But it definitely has something to do with relro, it's just not the
> > : whole story yet.
> >
> > I am still trying to wrap my head around all this, but it smells rather
> > dubious to map different segments over the same page. Is this something
> > that might happen widely and therefore MAP_FIXED_NOREPLACE is a no-go
> > when loading ELF segments? Or is this a special case we can detect?
> 
> Eww. FWIW, I would expect that to be rare and detectable.

OK, so Anshuman has confirmed [1] that the patch below fixes the issue
for him. I am sending this as an RFC because this is not really my area
and load_elf_binary is obscure as hell. The changelog could see much
more clear wording than I am able to provide. Any help would be highly
appreciated.

[1] http://lkml.kernel.org/r/b0a751c4-9552-87b4-c768-3e1b02c18b5c@linux.vnet.ibm.com

>From 97e7355a6dc31a73005fa806566a57eb5c38032b Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.com>
Date: Tue, 13 Feb 2018 10:50:53 +0100
Subject: [PATCH] elf: enforce MAP_FIXED on overlaying elf segments

Anshuman has reported that some ELF binaries in his environment fail to
start with
 [   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

The reason is that the above binary has overlapping elf segments:
  LOAD           0x0000000000000000 0x0000000010000000 0x0000000010000000
                 0x0000000000013a8c 0x0000000000013a8c  R E    10000
  LOAD           0x000000000001fd40 0x000000001002fd40 0x000000001002fd40
                 0x00000000000002c0 0x00000000000005e8  RW     10000
  LOAD           0x0000000000020328 0x0000000010030328 0x0000000010030328
                 0x0000000000000384 0x00000000000094a0  RW     10000

That binary has two RW LOAD segments, the first crosses a page border
into the second

0x1002fd40 (LOAD2-vaddr) + 0x5e8 (LOAD2-memlen) == 0x10030328 (LOAD3-vaddr)

Handle this situation by enforcing MAP_FIXED when we establish a
temporary brk VMA to handle overlapping segments. All other mappings
will still use MAP_FIXED_NOREPLACE.

Fixes: fs, elf: drop MAP_FIXED usage from elf_map
Reported-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
 fs/binfmt_elf.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 2f492dfcabde..4679d1d945f9 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -895,7 +895,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
 	   the correct location in memory. */
 	for(i = 0, elf_ppnt = elf_phdata;
 	    i < loc->elf_ex.e_phnum; i++, elf_ppnt++) {
-		int elf_prot = 0, elf_flags;
+		int elf_prot = 0, elf_flags, elf_fixed = MAP_FIXED_NOREPLACE;
 		unsigned long k, vaddr;
 		unsigned long total_size = 0;
 
@@ -927,6 +927,13 @@ static int load_elf_binary(struct linux_binprm *bprm)
 					 */
 				}
 			}
+
+			/*
+			 * Some binaries have overlapping elf segments and then
+			 * we have to forcefully map over an existing mapping
+			 * e.g. over this newly established brk mapping.
+			 */
+			elf_fixed = MAP_FIXED;
 		}
 
 		if (elf_ppnt->p_flags & PF_R)
@@ -944,7 +951,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_NOREPLACE;
+			elf_flags |= elf_fixed;
 		} else if (loc->elf_ex.e_type == ET_DYN) {
 			/*
 			 * This logic is run once for the first LOAD Program
@@ -980,7 +987,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
 				load_bias = ELF_ET_DYN_BASE;
 				if (current->flags & PF_RANDOMIZE)
 					load_bias += arch_mmap_rnd();
-				elf_flags |= MAP_FIXED_NOREPLACE;
+				elf_flags |= elf_fixed;
 			} else
 				load_bias = 0;
 
-- 
2.15.1

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply related	[flat|nested] 82+ messages in thread

* [RFC PATCH] elf: enforce MAP_FIXED on overlaying elf segments (was: Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE)
@ 2018-02-13 10:04                                                               ` Michal Hocko
  0 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-02-13 10:04 UTC (permalink / raw)
  To: Kees Cook
  Cc: Anshuman Khandual, Michael Ellerman, akpm, mm-commits, LKML,
	Linux-MM, linux-fsdevel, Linux-Next, Stephen Rothwell,
	Mark Brown, Linus Torvalds

On Fri 02-02-18 07:55:14, Kees Cook wrote:
> On Fri, Feb 2, 2018 at 12:40 AM, Michal Hocko <mhocko@kernel.org> wrote:
> > On Thu 01-02-18 14:10:07, Michal Hocko wrote:
> > Thanks a lot to Michael Matz for his background. He has pointed me to
> > the following two segments from your binary[1]
> >   LOAD           0x0000000000000000 0x0000000010000000 0x0000000010000000
> >                  0x0000000000013a8c 0x0000000000013a8c  R E    10000
> >   LOAD           0x000000000001fd40 0x000000001002fd40 0x000000001002fd40
> >                  0x00000000000002c0 0x00000000000005e8  RW     10000
> >   LOAD           0x0000000000020328 0x0000000010030328 0x0000000010030328
> >                  0x0000000000000384 0x00000000000094a0  RW     10000
> >
> > That binary has two RW LOAD segments, the first crosses a page border
> > into the second
> > 0x1002fd40 (LOAD2-vaddr) + 0x5e8 (LOAD2-memlen) == 0x10030328 (LOAD3-vaddr)
> >
> > He says
> > : This is actually an artifact of RELRO machinism.  The first RW mapping
> > : will be remapped as RO after relocations are applied (to increase
> > : security).
> > : Well, to be honest, normal relro binaries also don't have more than
> > : two LOAD segments, so whatever RHEL did to their compilation options,
> > : it's something in addition to just relro (which can be detected by
> > : having a GNU_RELRO program header)
> > : But it definitely has something to do with relro, it's just not the
> > : whole story yet.
> >
> > I am still trying to wrap my head around all this, but it smells rather
> > dubious to map different segments over the same page. Is this something
> > that might happen widely and therefore MAP_FIXED_NOREPLACE is a no-go
> > when loading ELF segments? Or is this a special case we can detect?
> 
> Eww. FWIW, I would expect that to be rare and detectable.

OK, so Anshuman has confirmed [1] that the patch below fixes the issue
for him. I am sending this as an RFC because this is not really my area
and load_elf_binary is obscure as hell. The changelog could see much
more clear wording than I am able to provide. Any help would be highly
appreciated.

[1] http://lkml.kernel.org/r/b0a751c4-9552-87b4-c768-3e1b02c18b5c@linux.vnet.ibm.com

>From 97e7355a6dc31a73005fa806566a57eb5c38032b Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.com>
Date: Tue, 13 Feb 2018 10:50:53 +0100
Subject: [PATCH] elf: enforce MAP_FIXED on overlaying elf segments

Anshuman has reported that some ELF binaries in his environment fail to
start with
 [   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

The reason is that the above binary has overlapping elf segments:
  LOAD           0x0000000000000000 0x0000000010000000 0x0000000010000000
                 0x0000000000013a8c 0x0000000000013a8c  R E    10000
  LOAD           0x000000000001fd40 0x000000001002fd40 0x000000001002fd40
                 0x00000000000002c0 0x00000000000005e8  RW     10000
  LOAD           0x0000000000020328 0x0000000010030328 0x0000000010030328
                 0x0000000000000384 0x00000000000094a0  RW     10000

That binary has two RW LOAD segments, the first crosses a page border
into the second

0x1002fd40 (LOAD2-vaddr) + 0x5e8 (LOAD2-memlen) == 0x10030328 (LOAD3-vaddr)

Handle this situation by enforcing MAP_FIXED when we establish a
temporary brk VMA to handle overlapping segments. All other mappings
will still use MAP_FIXED_NOREPLACE.

Fixes: fs, elf: drop MAP_FIXED usage from elf_map
Reported-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
 fs/binfmt_elf.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 2f492dfcabde..4679d1d945f9 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -895,7 +895,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
 	   the correct location in memory. */
 	for(i = 0, elf_ppnt = elf_phdata;
 	    i < loc->elf_ex.e_phnum; i++, elf_ppnt++) {
-		int elf_prot = 0, elf_flags;
+		int elf_prot = 0, elf_flags, elf_fixed = MAP_FIXED_NOREPLACE;
 		unsigned long k, vaddr;
 		unsigned long total_size = 0;
 
@@ -927,6 +927,13 @@ static int load_elf_binary(struct linux_binprm *bprm)
 					 */
 				}
 			}
+
+			/*
+			 * Some binaries have overlapping elf segments and then
+			 * we have to forcefully map over an existing mapping
+			 * e.g. over this newly established brk mapping.
+			 */
+			elf_fixed = MAP_FIXED;
 		}
 
 		if (elf_ppnt->p_flags & PF_R)
@@ -944,7 +951,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_NOREPLACE;
+			elf_flags |= elf_fixed;
 		} else if (loc->elf_ex.e_type == ET_DYN) {
 			/*
 			 * This logic is run once for the first LOAD Program
@@ -980,7 +987,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
 				load_bias = ELF_ET_DYN_BASE;
 				if (current->flags & PF_RANDOMIZE)
 					load_bias += arch_mmap_rnd();
-				elf_flags |= MAP_FIXED_NOREPLACE;
+				elf_flags |= elf_fixed;
 			} else
 				load_bias = 0;
 
-- 
2.15.1

-- 
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>

^ permalink raw reply related	[flat|nested] 82+ messages in thread

* [RFC PATCH] elf: enforce MAP_FIXED on overlaying elf segments (was: Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE)
@ 2018-02-13 10:04                                                               ` Michal Hocko
  0 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2018-02-13 10:04 UTC (permalink / raw)
  To: Kees Cook
  Cc: Anshuman Khandual, Michael Ellerman, akpm, mm-commits, LKML,
	Linux-MM, linux-fsdevel, Linux-Next, Stephen Rothwell,
	Mark Brown, Linus Torvalds

On Fri 02-02-18 07:55:14, Kees Cook wrote:
> On Fri, Feb 2, 2018 at 12:40 AM, Michal Hocko <mhocko@kernel.org> wrote:
> > On Thu 01-02-18 14:10:07, Michal Hocko wrote:
> > Thanks a lot to Michael Matz for his background. He has pointed me to
> > the following two segments from your binary[1]
> >   LOAD           0x0000000000000000 0x0000000010000000 0x0000000010000000
> >                  0x0000000000013a8c 0x0000000000013a8c  R E    10000
> >   LOAD           0x000000000001fd40 0x000000001002fd40 0x000000001002fd40
> >                  0x00000000000002c0 0x00000000000005e8  RW     10000
> >   LOAD           0x0000000000020328 0x0000000010030328 0x0000000010030328
> >                  0x0000000000000384 0x00000000000094a0  RW     10000
> >
> > That binary has two RW LOAD segments, the first crosses a page border
> > into the second
> > 0x1002fd40 (LOAD2-vaddr) + 0x5e8 (LOAD2-memlen) == 0x10030328 (LOAD3-vaddr)
> >
> > He says
> > : This is actually an artifact of RELRO machinism.  The first RW mapping
> > : will be remapped as RO after relocations are applied (to increase
> > : security).
> > : Well, to be honest, normal relro binaries also don't have more than
> > : two LOAD segments, so whatever RHEL did to their compilation options,
> > : it's something in addition to just relro (which can be detected by
> > : having a GNU_RELRO program header)
> > : But it definitely has something to do with relro, it's just not the
> > : whole story yet.
> >
> > I am still trying to wrap my head around all this, but it smells rather
> > dubious to map different segments over the same page. Is this something
> > that might happen widely and therefore MAP_FIXED_NOREPLACE is a no-go
> > when loading ELF segments? Or is this a special case we can detect?
> 
> Eww. FWIW, I would expect that to be rare and detectable.

OK, so Anshuman has confirmed [1] that the patch below fixes the issue
for him. I am sending this as an RFC because this is not really my area
and load_elf_binary is obscure as hell. The changelog could see much
more clear wording than I am able to provide. Any help would be highly
appreciated.

[1] http://lkml.kernel.org/r/b0a751c4-9552-87b4-c768-3e1b02c18b5c@linux.vnet.ibm.com

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [RFC PATCH] elf: enforce MAP_FIXED on overlaying elf segments (was: Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE)
  2018-02-13 10:04                                                               ` Michal Hocko
@ 2018-02-14 16:30                                                                 ` Khalid Aziz
  -1 siblings, 0 replies; 82+ messages in thread
From: Khalid Aziz @ 2018-02-14 16:30 UTC (permalink / raw)
  To: Michal Hocko, Kees Cook
  Cc: Anshuman Khandual, Michael Ellerman, akpm, mm-commits, LKML,
	Linux-MM, linux-fsdevel, Linux-Next, Stephen Rothwell,
	Mark Brown, Linus Torvalds

On Tue, 2018-02-13 at 11:04 +0100, Michal Hocko wrote:
> 
> From 97e7355a6dc31a73005fa806566a57eb5c38032b Mon Sep 17 00:00:00
> 2001
> From: Michal Hocko <mhocko@suse.com>
> Date: Tue, 13 Feb 2018 10:50:53 +0100
> Subject: [PATCH] elf: enforce MAP_FIXED on overlaying elf segments
> 
> Anshuman has reported that some ELF binaries in his environment fail
> to
> start with
>  [   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
> 
> The reason is that the above binary has overlapping elf segments:
>   LOAD           0x0000000000000000 0x0000000010000000
> 0x0000000010000000
>                  0x0000000000013a8c 0x0000000000013a8c  R E    10000
>   LOAD           0x000000000001fd40 0x000000001002fd40
> 0x000000001002fd40
>                  0x00000000000002c0 0x00000000000005e8  RW     10000
>   LOAD           0x0000000000020328 0x0000000010030328
> 0x0000000010030328
>                  0x0000000000000384 0x00000000000094a0  RW     10000
> 
> That binary has two RW LOAD segments, the first crosses a page border
> into the second
> 
> 0x1002fd40 (LOAD2-vaddr) + 0x5e8 (LOAD2-memlen) == 0x10030328 (LOAD3-
> vaddr)
> 
> Handle this situation by enforcing MAP_FIXED when we establish a
> temporary brk VMA to handle overlapping segments. All other mappings
> will still use MAP_FIXED_NOREPLACE.
> 
> Fixes: fs, elf: drop MAP_FIXED usage from elf_map
> Reported-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
> 

Looks reasonable to me.

Reviewed-by: Khalid Aziz <khalid.aziz@oracle.com>

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [RFC PATCH] elf: enforce MAP_FIXED on overlaying elf segments (was: Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE)
@ 2018-02-14 16:30                                                                 ` Khalid Aziz
  0 siblings, 0 replies; 82+ messages in thread
From: Khalid Aziz @ 2018-02-14 16:30 UTC (permalink / raw)
  To: Michal Hocko, Kees Cook
  Cc: Anshuman Khandual, Michael Ellerman, akpm, mm-commits, LKML,
	Linux-MM, linux-fsdevel, Linux-Next, Stephen Rothwell,
	Mark Brown, Linus Torvalds

On Tue, 2018-02-13 at 11:04 +0100, Michal Hocko wrote:
> 
> From 97e7355a6dc31a73005fa806566a57eb5c38032b Mon Sep 17 00:00:00
> 2001
> From: Michal Hocko <mhocko@suse.com>
> Date: Tue, 13 Feb 2018 10:50:53 +0100
> Subject: [PATCH] elf: enforce MAP_FIXED on overlaying elf segments
> 
> Anshuman has reported that some ELF binaries in his environment fail
> to
> start with
>  [   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
> 
> The reason is that the above binary has overlapping elf segments:
>   LOAD           0x0000000000000000 0x0000000010000000
> 0x0000000010000000
>                  0x0000000000013a8c 0x0000000000013a8c  R E    10000
>   LOAD           0x000000000001fd40 0x000000001002fd40
> 0x000000001002fd40
>                  0x00000000000002c0 0x00000000000005e8  RW     10000
>   LOAD           0x0000000000020328 0x0000000010030328
> 0x0000000010030328
>                  0x0000000000000384 0x00000000000094a0  RW     10000
> 
> That binary has two RW LOAD segments, the first crosses a page border
> into the second
> 
> 0x1002fd40 (LOAD2-vaddr) + 0x5e8 (LOAD2-memlen) == 0x10030328 (LOAD3-
> vaddr)
> 
> Handle this situation by enforcing MAP_FIXED when we establish a
> temporary brk VMA to handle overlapping segments. All other mappings
> will still use MAP_FIXED_NOREPLACE.
> 
> Fixes: fs, elf: drop MAP_FIXED usage from elf_map
> Reported-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
> 

Looks reasonable to me.

Reviewed-by: Khalid Aziz <khalid.aziz@oracle.com>

--
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>

^ permalink raw reply	[flat|nested] 82+ messages in thread

end of thread, other threads:[~2018-02-14 16:30 UTC | newest]

Thread overview: 82+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-05  0:20 mmotm 2018-01-04-16-19 uploaded akpm
2018-01-05  0:20 ` akpm
2018-01-05  6:43 ` Anshuman Khandual
2018-01-05  6:43   ` Anshuman Khandual
2018-01-05  8:46   ` Michal Hocko
2018-01-05  8:46     ` Michal Hocko
2018-01-07  6:49     ` Anshuman Khandual
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  9:02         ` Michal Hocko
2018-01-07 11:26         ` Michael Ellerman
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  3:02             ` Anshuman Khandual
2018-01-08 22:12             ` Michael Ellerman
2018-01-08 22:12               ` Michael Ellerman
2018-01-08 22:12               ` Michael Ellerman
2018-01-09 11:48               ` Anshuman Khandual
2018-01-09 11:48                 ` Anshuman Khandual
2018-01-09 16:13                 ` Michal Hocko
2018-01-09 16:13                   ` Michal Hocko
2018-01-11 10:08                   ` Anshuman Khandual
2018-01-11 10:08                     ` Anshuman Khandual
2018-01-17  8:07                     ` Michal Hocko
2018-01-17  8:07                       ` Michal Hocko
2018-01-23 11:25                       ` Anshuman Khandual
2018-01-23 11:25                         ` Anshuman Khandual
2018-01-23 12:45                         ` Michal Hocko
2018-01-23 12:45                           ` Michal Hocko
2018-01-23 15:58                           ` Anshuman Khandual
2018-01-23 15:58                             ` Anshuman Khandual
2018-01-23 16:06                             ` Michal Hocko
2018-01-23 16:06                               ` Michal Hocko
2018-01-24  5:09                               ` Anshuman Khandual
2018-01-24  5:09                                 ` Anshuman Khandual
2018-01-24  9:05                                 ` Michal Hocko
2018-01-24  9:05                                   ` Michal Hocko
2018-01-26 12:34                                   ` Anshuman Khandual
2018-01-26 12:34                                     ` Anshuman Khandual
2018-01-26 14:04                                     ` Michal Hocko
2018-01-26 14:04                                       ` Michal Hocko
2018-01-29  2:47                                       ` Anshuman Khandual
2018-01-29  2:47                                         ` Anshuman Khandual
2018-01-29  5:32                                         ` Anshuman Khandual
2018-01-29  5:32                                           ` Anshuman Khandual
2018-01-29 13:22                                           ` Michal Hocko
2018-01-29 13:22                                             ` Michal Hocko
2018-01-30  3:35                                             ` Michael Ellerman
2018-01-30  3:35                                               ` Michael Ellerman
2018-01-30  9:42                                               ` Michal Hocko
2018-01-30  9:42                                                 ` Michal Hocko
2018-01-31  5:05                                                 ` Anshuman Khandual
2018-01-31  5:05                                                   ` Anshuman Khandual
2018-01-31 13:19                                                   ` Michal Hocko
2018-01-31 13:19                                                     ` Michal Hocko
2018-02-01  3:13                                                     ` Anshuman Khandual
2018-02-01  3:13                                                       ` Anshuman Khandual
2018-02-01 13:10                                                       ` Michal Hocko
2018-02-01 13:10                                                         ` Michal Hocko
2018-02-01 13:40                                                         ` Michal Hocko
2018-02-01 13:40                                                           ` Michal Hocko
2018-02-01 20:55                                                           ` Kees Cook
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-13 10:04                                                               ` Michal Hocko
2018-02-13 10:04                                                               ` Michal Hocko
2018-02-14 16:30                                                               ` Khalid Aziz
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 13:48                                                         ` Michal Hocko
2018-02-01 21:06                                                         ` Kees Cook
2018-02-01 21:06                                                           ` Kees Cook
2018-02-12 14:48                                                         ` Michal Hocko
2018-02-12 14:48                                                           ` Michal Hocko
2018-02-13  1:02                                                           ` Anshuman Khandual
2018-02-13  1:02                                                             ` Anshuman Khandual
2018-02-13  6:49                                                         ` Anshuman Khandual
2018-02-13  6:49                                                           ` Anshuman Khandual
2018-02-13 10:00                                                           ` Michal Hocko
2018-02-13 10:00                                                             ` Michal Hocko
2018-01-05 12:14   ` mmotm 2018-01-04-16-19 uploaded Michal Hocko
2018-01-05 12:14     ` Michal Hocko

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.