Hi all,
Please do not add any material not destined to be merged before v6.7-rc1
into your linux-next included branches until after v6.7-rc1 has been
released. Bug fixes are always welcome.
Changes since 20231106:
Non-merge commits (relative to Linus' tree): 1460
1701 files changed, 48749 insertions(+), 38502 deletions(-)
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There is also the merge.log file in the Next
directory. Between each merge, the tree was built with a ppc64_defconfig
for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm
and a native build of tools/perf. After the final fixups (if any), I do
an x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, arm64, s390, sparc and sparc64
defconfig and htmldocs. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 369 trees (counting Linus' and 105 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (d2f51b3516da Merge tag 'rtc-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux)
Merging fixes/fixes (2dde18cd1d8f Linux 6.5)
Merging mm-hotfixes/mm-hotfixes-unstable (27969c8df896 kexec-fix-kexec_file-dependencies-fix)
Merging kbuild-current/fixes (04714e55eb72 kconfig: avoid an infinite loop in oldconfig/syncconfig)
Merging arc-current/for-curr (0bb80ecc33a8 Linux 6.6-rc1)
Merging arm-current/fixes (2dde18cd1d8f Linux 6.5)
Merging arm64-fixes/for-next/fixes (4785aa802853 cpuidle, ACPI: Evaluate LPI arch_flags for broadcast timer)
Merging arm-soc-fixes/arm/fixes (736a4aad8a9f Merge tag 'renesas-fixes-for-v6.6-tag3' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/fixes)
Merging davinci-current/davinci/for-current (06c2afb862f9 Linux 6.5-rc1)
Merging drivers-memory-fixes/fixes (0bb80ecc33a8 Linux 6.6-rc1)
Merging tee-fixes/fixes (ceaa837f96ad Linux 6.2-rc8)
Merging m68k-current/for-linus (03191fb3db3d m68k: lib: Include <linux/libgcc.h> for __muldi3())
Merging powerpc-fixes/fixes (47b8def9358c powerpc/mm: Avoid calling arch_enter/leave_lazy_mmu() in set_ptes)
Merging s390-fixes/fixes (ffc253263a13 Linux 6.6)
Merging sparc/master (2d2b17d08bfc sparc: Unbreak the build)
Merging fscrypt-current/for-current (4bcf6f827a79 fscrypt: check for NULL keyring in fscrypt_put_master_key_activeref())
Merging fsverity-current/for-current (a075bacde257 fsverity: don't drop pagecache at end of FS_IOC_ENABLE_VERITY)
Merging net/main (c1ed833e0b3b Merge branch 'smc-fixes')
Merging bpf/master (d84b139f53e8 selftests/bpf: Fix broken build where char is unsigned)
Merging ipsec/master (de5724ca38fd xfrm: fix a data-race in xfrm_lookup_with_ifid())
Merging netfilter/main (016b9332a334 netlink: fill in missing MODULE_DESCRIPTION())
Merging ipvs/main (a63b6622120c net/sched: act_ct: additional checks for outdated flows)
Merging wireless/for-next (55c900477f5b net: fill in MODULE_DESCRIPTION()s under drivers/net/)
Merging wpan/master (2d1c882d4434 Merge tag 'mlx5-fixes-2023-10-12' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux)
Merging rdma-fixes/for-rc (94f6f0550c62 Linux 6.6-rc5)
Merging sound-current/for-linus (dc6e08b1a2ae ALSA: hda: cs35l41: Fix missing error code in cs35l41_smart_amp())
Merging sound-asoc-fixes/for-linus (4bdcbc31ad21 ASoC: dapm: fix clock get name)
Merging regmap-fixes/for-linus (f33804f1597d Merge remote-tracking branch 'regmap/for-6.6' into regmap-linus)
Merging regulator-fixes/for-linus (bc00d9f3813a regulator: qcom-rpmh: Fix smps4 regulator for pm8550ve)
Merging spi-fixes/for-linus (14c4fb111a39 Merge remote-tracking branch 'spi/for-6.6' into spi-linus)
Merging pci-current/for-linus (27beb3ca347f Merge tag 'pci-v6.7-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci)
Merging driver-core.current/driver-core-linus (d2f51b3516da Merge tag 'rtc-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux)
Merging tty.current/tty-linus (d2f51b3516da Merge tag 'rtc-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux)
Merging usb.current/usb-linus (d2f51b3516da Merge tag 'rtc-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux)
Merging usb-serial-fixes/usb-linus (52480e1f1a25 USB: serial: option: add Fibocom to DELL custom modem FM101R-GL)
Merging phy/fixes (05d3ef8bba77 Linux 6.6-rc7)
Merging staging.current/staging-linus (d2f51b3516da Merge tag 'rtc-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux)
Merging iio-fixes/fixes-togreg (bce3ab29a6c0 iio: common: ms_sensors: ms_sensors_i2c: fix humidity conversion time table)
Merging counter-current/counter-current (58720809f527 Linux 6.6-rc6)
Merging char-misc.current/char-misc-linus (d2f51b3516da Merge tag 'rtc-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux)
Merging soundwire-fixes/fixes (58720809f527 Linux 6.6-rc6)
Merging thunderbolt-fixes/fixes (ec4405ed9203 thunderbolt: Call tb_switch_put() once DisplayPort bandwidth request is finished)
Merging input-current/for-linus (5c15c60e7be6 Input: powermate - fix use-after-free in powermate_config_complete)
Merging crypto-current/master (a312e07a65fb crypto: adiantum - flush destination page before unmapping)
Merging vfio-fixes/for-linus (c777b11d34e0 vfio/mdev: Fix a null-ptr-deref bug for mdev_unregister_parent())
Merging kselftest-fixes/fixes (cf5a103c98a6 selftests/user_events: Fix abi_test for BE archs)
Merging modules-fixes/modules-linus (f412eef03938 Documentation: livepatch: module-elf-format: Remove local klp_modinfo definition)
Merging dmaengine-fixes/fixes (58720809f527 Linux 6.6-rc6)
Merging backlight-fixes/for-backlight-fixes (88603b6dc419 Linux 6.2-rc2)
Merging mtd-fixes/mtd/fixes (f6ca3fb6978f mtd: rawnand: Ensure the nand chip supports cached reads)
Merging mfd-fixes/for-mfd-fixes (88603b6dc419 Linux 6.2-rc2)
Merging v4l-dvb-fixes/fixes (c46f16f156ac media: i2c: ov8858: Don't set fwnode in the driver)
Merging reset-fixes/reset/fixes (3a2390c6777e reset: uniphier-glue: Fix possible null-ptr-deref)
Merging mips-fixes/mips-fixes (8a749fd1a872 Linux 6.6-rc4)
Merging at91-fixes/at91-fixes (0bb80ecc33a8 Linux 6.6-rc1)
Merging omap-fixes/fixes (0b9a4a67c60d clk: ti: Fix missing omap5 mcbsp functional clock and aliases)
Merging kvm-fixes/master (ffc253263a13 Linux 6.6)
Merging kvms390-fixes/master (f87ef5723536 KVM: s390: fix gisa destroy operation might lead to cpu stalls)
Merging hwmon-fixes/hwmon (9da2901c4733 hwmon: (pmbus/mp2975) Move PGOOD fix)
Merging nvdimm-fixes/libnvdimm-fixes (33908660e814 ACPI: NFIT: Fix incorrect calculation of idt size)
Merging cxl-fixes/fixes (8f61d48c83f6 tools/testing/cxl: Slow down the mock firmware transfer)
Merging btrfs-fixes/next-fixes (db2fc5f63a3a Merge branch 'misc-6.7' into next-fixes)
Merging vfs-fixes/fixes (dc32464a5fe4 ceph_wait_on_conflict_unlink(): grab reference before dropping ->d_lock)
Merging dma-mapping-fixes/for-linus (d5090484b021 swiotlb: do not try to allocate a TLB bigger than MAX_ORDER pages)
Merging drivers-x86-fixes/fixes (3bde7ec13c97 platform/x86: Add s2idle quirk for more Lenovo laptops)
Merging samsung-krzk-fixes/fixes (0bb80ecc33a8 Linux 6.6-rc1)
Merging pinctrl-samsung-fixes/fixes (0bb80ecc33a8 Linux 6.6-rc1)
Merging devicetree-fixes/dt/linus (19007c629c63 dt-bindings: trivial-devices: Fix MEMSIC MXC4005 compatible string)
Merging dt-krzk-fixes/fixes (0bb80ecc33a8 Linux 6.6-rc1)
Merging scsi-fixes/fixes (097c06394c83 scsi: qla2xxx: Fix double free of dsd_list during driver load)
Merging drm-fixes/drm-fixes (44117828ed5c Merge tag 'amd-drm-fixes-6.6-2023-10-25' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes)
Merging drm-intel-fixes/for-linux-next-fixes (4cbed7702eb7 drm/i915/pmu: Check if pmu is closed before stopping event)
Merging mmc-fixes/fixes (421b605edb1c Revert "mmc: core: Capture correct oemid-bits for eMMC cards")
Merging rtc-fixes/rtc-fixes (08279468a294 rtc: sunplus: fix format string for printing resource)
Merging gnss-fixes/gnss-linus (58720809f527 Linux 6.6-rc6)
Merging hyperv-fixes/hyperv-fixes (42999c904612 hv/hv_kvp_daemon:Support for keyfile based connection profile)
Merging soc-fsl-fixes/fix (06c2afb862f9 Linux 6.5-rc1)
Merging risc-v-fixes/fixes (3fec323339a4 drivers: perf: Fix panic in riscv SBI mmap support)
Merging riscv-dt-fixes/riscv-dt-fixes (cf98fe6b579e riscv: dts: starfive: visionfive 2: correct spi's ss pin)
Merging riscv-soc-fixes/riscv-soc-fixes (0bb80ecc33a8 Linux 6.6-rc1)
Merging fpga-fixes/fixes (03d4bf9ff34a fpga: Fix memory leak for fpga_region_test_class_find())
Merging spdx/spdx-linus (d2f51b3516da Merge tag 'rtc-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux)
Merging gpio-brgl-fixes/gpio/for-current (05d3ef8bba77 Linux 6.6-rc7)
Merging gpio-intel-fixes/fixes (0bb80ecc33a8 Linux 6.6-rc1)
Merging pinctrl-intel-fixes/fixes (2d325e54d9e2 pinctrl: baytrail: fix debounce disable case)
Merging erofs-fixes/fixes (3048102d9d68 erofs: update documentation)
Merging kunit-fixes/kunit-fixes (0bb80ecc33a8 Linux 6.6-rc1)
Merging ubifs-fixes/fixes (2241ab53cbb5 Linux 6.2-rc5)
Merging memblock-fixes/fixes (55122e0130e5 memblock tests: fix warning ‘struct seq_file’ declared inside parameter list)
Merging nfsd-fixes/nfsd-fixes (0d32a6bbb8e7 NFSD: Fix zero NFSv4 READ results when RQ_SPLICE_OK is not set)
Merging irqchip-fixes/irq/irqchip-fixes (b673fe1a6229 MAINTAINERS: Remove myself from the general IRQ subsystem maintenance)
Merging renesas-fixes/fixes (9eab43facdad soc: renesas: ARCH_R9A07G043 depends on !RISCV_ISA_ZICBOM)
Merging broadcom-fixes/fixes (9abf2313adc1 Linux 6.1-rc1)
Merging perf-current/perf-tools (fed3a1be6433 Merge tag 'perf-tools-fixes-for-v6.6-2-2023-10-20' into perf-tools-next)
Merging efi-fixes/urgent (c03d21f05e76 Merge 3rd batch of EFI fixes into efi/urgent)
Merging zstd-fixes/zstd-linus (f064f4e5ecb1 zstd: Fix array-index-out-of-bounds UBSAN warning)
Merging battery-fixes/fixes (8894b4325488 power: supply: qcom_battmgr: fix enable request endianness)
Merging uml-fixes/fixes (73a23d771033 um: harddog: fix modular build)
Merging asahi-soc-fixes/asahi-soc/fixes (568035b01cfb Linux 6.0-rc1)
Merging iommufd-fixes/for-rc (0bb80ecc33a8 Linux 6.6-rc1)
Merging rust-fixes/rust-fixes (cfd96726e611 rust: docs: fix logo replacement)
Merging v9fs-fixes/fixes/next (2dde18cd1d8f Linux 6.5)
Merging w1-fixes/fixes (0bb80ecc33a8 Linux 6.6-rc1)
Merging pmdomain-fixes/fixes (b131329b9bfb pmdomain: amlogic: Fix mask for the second NNA mem PD domain)
Merging overlayfs-fixes/ovl-fixes (beae836e9c61 ovl: temporarily disable appending lowedirs)
Merging drm-misc-fixes/for-linux-next-fixes (0e8b9f258bae drm/qxl: prevent memory leak)
Merging mm-stable/mm-stable (ffc253263a13 Linux 6.6)
Merging mm-nonmm-stable/mm-nonmm-stable (ffc253263a13 Linux 6.6)
Merging mm/mm-everything (4f5e05649c22 mm: zswap: fix the lack of page lru flag in zswap_writeback_entry)
Merging kbuild/for-next (5f56cb030e4b kbuild: support 'userldlibs' syntax)
Merging clang-format/clang-format (5d0c230f1de8 Linux 6.5-rc4)
Merging perf/perf-tools-next (fed3a1be6433 Merge tag 'perf-tools-fixes-for-v6.6-2-2023-10-20' into perf-tools-next)
Merging compiler-attributes/compiler-attributes (5d0c230f1de8 Linux 6.5-rc4)
Merging dma-mapping/for-next (a409d9600959 dma-mapping: fix dma_addressing_limited() if dma_range_map can't cover all system RAM)
Merging asm-generic/master (550087a0ba91 hexagon: Remove unusable symbols from the ptrace.h uapi)
Merging arc/for-next (0bb80ecc33a8 Linux 6.6-rc1)
Merging arm/for-next (c7368ddba2ff ARM: 9326/1: make <linux/uaccess.h> self-contained for ARM)
Merging arm64/for-next/core (14dcf78a6c04 Merge branch 'for-next/cpus_have_const_cap' into for-next/core)
Merging arm-perf/for-next/perf (b805cafc604b perf: hisi: Fix use-after-free when register pmu fails)
Merging arm-soc/for-next (1b52f65d88ad Merge branch 'soc/defconfig' into for-next)
Merging amlogic/for-next (996fc07dce79 Merge branch 'v6.7/defconfig' into for-next)
Merging asahi-soc/asahi-soc/for-next (ffc253263a13 Linux 6.6)
Merging aspeed/for-next (3be891e01a89 Merge branches 'defconfig-for-v6.7', 'dt-for-v6.7' and 'soc-for-v6.7' into for-next)
Merging at91/at91-next (3cec9514911c ARM: dts: at91: sam9x60_curiosity: Add mandatory dt property for RTT)
Merging broadcom/next (62a3c97f8167 Merge branch 'devicetree/next' into next)
Merging davinci/davinci/for-next (06c2afb862f9 Linux 6.5-rc1)
Merging drivers-memory/for-next (09de3691daab memory: Use device_get_match_data())
Merging imx-mxs/for-next (fa81543ef854 Merge branch 'imx/defconfig' into for-next)
Merging mediatek/for-next (9802b60bd6d8 Merge branch 'v6.6-next/soc' into for-next)
Merging mvebu/for-next (93e6b023e552 Merge branch 'mvebu/dt64' into mvebu/for-next)
Merging omap/for-next (cb1114df7bb0 Merge branch 'fixes' into for-next)
Merging qcom/for-next (2b05c2dc230b Merge branches 'arm64-defconfig-for-6.7', 'arm64-fixes-for-6.6', 'arm64-for-6.7', 'clk-for-6.7', 'drivers-for-6.7' and 'dts-for-6.7' into for-next)
Merging renesas/next (fb39831a07ec Merge branch 'renesas-fixes-for-v6.6' into renesas-next)
Merging reset/reset/next (417a3a5ae44a reset: ti: syscon: remove unneeded call to platform_set_drvdata())
Merging rockchip/for-next (043d3ef3344a Merge branch 'v6.8-clk/next' into for-next)
Merging samsung-krzk/for-next (b7df1b3a7a1b Merge branch 'next/dt' into for-next)
Merging scmi/for-linux-next (93a72958a951 Merge branch 'for-next/ffa/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into for-linux-next)
Merging stm32/stm32-next (1aeb02d3f2c5 ARM: dts: stm32: add SDIO pinctrl sleep support on stm32f7 boards)
Merging sunxi/sunxi/for-next (c3f7c14856eb riscv: dts: allwinner: convert isa detection to new properties)
Merging tee/next (6a8b7e801054 tee: optee: Use kmemdup() to replace kmalloc + memcpy)
Merging tegra/for-next (650220c2b474 Merge branch for-6.7/arm64/dt into for-next)
Merging ti/ti-next (2234981539e7 Merge branch 'ti-k3-dts-next' into ti-next)
Merging xilinx/for-next (7d2da28125ce Merge branch 'zynqmp/dt' into for-next)
Merging clk/clk-next (0a6d7f8275f2 Merge branch 'clk-cleanup' into clk-next)
Merging clk-imx/for-next (2838820800dc clk: imx: imx8qm/qxp: add more resources to whitelist)
Merging clk-renesas/renesas-clk (4bce4bedbe6d clk: renesas: r9a08g045: Add clock and reset support for SDHI1 and SDHI2)
Merging csky/linux-next (2c40c1c6adab Merge tag 'usb-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb)
Merging loongarch/loongarch-next (99070159221b LoongArch: Support PREEMPT_DYNAMIC with static keys)
Merging m68k/for-next (03191fb3db3d m68k: lib: Include <linux/libgcc.h> for __muldi3())
Merging m68knommu/for-next (2508b608f402 m68k: 68000: fix warning in timer code)
Merging microblaze/next (65d6e954e378 Merge tag 'gfs2-v6.5-rc5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2)
Merging mips/mips-next (4b7d3ab44565 MIPS: AR7: remove platform)
Merging openrisc/for-next (c289330331eb openrisc: Remove kernel-doc marker from ioremap comment)
Merging parisc-hd/for-next (8a32aa17c1cd fbdev: stifb: Make the STI next font pointer a 32-bit signed offset)
Merging powerpc/next (303d77a6e170 Merge branch 'topic/ppc-kvm' into next)
Merging soc-fsl/next (fb9c384625dd bus: fsl-mc: fsl-mc-allocator: Drop a write-only variable)
Merging risc-v/for-next (dbfbda3bd6bf riscv: mm: update T-Head memory type definitions)
CONFLICT (content): Merge conflict in arch/riscv/include/asm/csr.h
CONFLICT (content): Merge conflict in arch/riscv/kernel/irq.c
Merging riscv-dt/riscv-dt-for-next (b99df6281891 riscv: dts: sophgo: remove address-cells from intc node)
Merging riscv-soc/riscv-soc-for-next (22dedf8f4570 soc/microchip: mpfs-sys-controller: Convert to platform remove callback returning void)
Merging s390/for-next (02e790ee3077 s390/mm: make pte_free_tlb() similar to pXd_free_tlb())
Merging sh/for-next (63f1ee206170 locking/atomic: sh: Use generic_cmpxchg_local for arch_cmpxchg_local())
Merging uml/next (974b808d85ab um: virt-pci: fix missing declaration warning)
Merging xtensa/xtensa-for-next (a83a72730c33 xtensa: import ESP32S3 core variant)
Merging bcachefs/for-next (c7046ed0cf9b bcachefs: Improve stripe checksum error message)
CONFLICT (content): Merge conflict in fs/bcachefs/btree_cache.c
CONFLICT (content): Merge conflict in fs/bcachefs/btree_key_cache.c
Merging pidfd/for-next (a901a3568fd2 Merge tag 'iomap-6.5-merge-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux)
Merging fscrypt/for-next (15baf55481de fscrypt: track master key presence separately from secret)
Merging afs/afs-next (0a278bc196e7 afs: Automatically generate trace tag enums)
Merging btrfs/for-next (c6e8f898f56f btrfs: open code timespec64 in struct btrfs_inode)
Merging ceph/master (87cbdc270d48 libceph: check data length when sparse read finishes)
CONFLICT (content): Merge conflict in fs/ceph/inode.c
Merging cifs/for-next (bc05fd25483b smb3: minor cleanup of session handling code)
Merging configfs/for-next (4425c1d9b44d configfs: improve item creation performance)
Merging ecryptfs/next (a3d78fe3e1ae fs: ecryptfs: comment typo fix)
Merging erofs/dev (1a0ac8bd7a4f erofs: fix erofs_insert_workgroup() lockref usage)
Merging exfat/dev (1373ca10ec04 exfat: fix ctime is not updated)
Merging ext3/for_next (7f680e5f256f Pull ext2 conversion of directory code to folios.)
Merging ext4/dev (91562895f803 ext4: properly sync file size update after O_SYNC direct IO)
Merging f2fs/dev (1e7bef5f90ed f2fs: finish previous checkpoints before returning from remount)
Merging fsverity/for-next (919dc320956e fsverity: skip PKCS#7 parser when keyring is empty)
Merging fuse/for-next (513dfacefd71 fuse: share lookup state between submount and its parent)
Merging gfs2/for-next (0cdc6f44e9fd gfs2: don't withdraw if init_threads() got interrupted)
Merging jfs/jfs-next (5afb50b46a98 jfs: fix shift-out-of-bounds in dbJoin)
Merging ksmbd/ksmbd-for-next (b5fcfb5619e6 ksmbd: fix kernel-doc comment of ksmbd_vfs_kern_path_locked())
Merging nfs/linux-next (f003a717ae90 nfs: Convert nfs_symlink() to use a folio)
Merging nfs-anna/linux-next (379e4adfddd6 NFSv4.1: fixup use EXCHGID4_FLAG_USE_PNFS_DS for DS server)
Merging nfsd/nfsd-next (3fd2ca5be07f svcrdma: Fix tracepoint printk format)
Merging ntfs3/master (e4494770a5ca fs/ntfs3: Avoid possible memory leak)
Merging orangefs/for-next (31720a2b109b orangefs: Fix kmemleak in orangefs_{kernel,client}_debug_init())
Merging overlayfs/overlayfs-next (24e16e385f22 ovl: add support for appending lowerdirs one by one)
Merging ubifs/next (75690493591f ubifs: ubifs_link: Fix wrong name len calculating when UBIFS is encrypted)
Merging v9fs/9p-next (ce0708796420 9p/net: fix possible memory leak in p9_check_errors())
Merging v9fs-ericvh/ericvh/for-next (2dde18cd1d8f Linux 6.5)
Merging xfs/for-next (14a537983b22 xfs: allow read IO and FICLONE to run concurrently)
CONFLICT (content): Merge conflict in fs/xfs/libxfs/xfs_rtbitmap.c
CONFLICT (content): Merge conflict in fs/xfs/xfs_rtalloc.c
Merging zonefs/for-next (8812387d0569 zonefs: set FMODE_CAN_ODIRECT instead of a dummy direct_IO method)
Merging iomap/iomap-for-next (3ac974796e5d iomap: fix short copy in iomap_write_iter())
Merging djw-vfs/vfs-for-next (ce85a1e04645 xfs: stabilize fs summary counters for online fsck)
Merging file-locks/locks-next (e0152e7481c6 Merge tag 'riscv-for-linus-6.6-mw1' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux)
Merging iversion/iversion-next (e0152e7481c6 Merge tag 'riscv-for-linus-6.6-mw1' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux)
Merging vfs-brauner/vfs.all (c1279eea4989 Merge branch 'vfs.f_fsid' into vfs.all)
Merging vfs/for-next (1aee9158bc97 nfsd: lock_rename() needs both directories to live on the same fs)
Merging printk/for-next (b4908d68609b Merge branch 'for-6.7' into for-next)
Merging pci/next (27beb3ca347f Merge tag 'pci-v6.7-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci)
Merging pstore/for-next/pstore (a19d48f7c5d5 pstore/platform: Add check for kstrdup)
Merging hid/for-next (55ec92989f9b Merge branch 'for-6.6/upstream-fixes' into for-next)
Merging i2c/i2c/for-next (b871ee43a733 Merge branch 'i2c/for-mergewindow' into i2c/for-next)
Merging i3c/i3c/next (9fd00df05e81 i3c: master: handle IBIs in order they came)
Merging dmi/dmi-for-next (13a0ac816d22 firmware: dmi: Fortify entry point length checks)
Merging hwmon-staging/hwmon-next (0f564130e5c7 hwmon: (aquacomputer_d5next) Check if temp sensors of legacy devices are connected)
Merging jc_docs/docs-next (cf63348b4c45 scripts/kernel-doc: Fix the regex for matching -Werror flag)
Merging v4l-dvb/master (3e238417254b media: nuvoton: VIDEO_NPCM_VCD_ECE should depend on ARCH_NPCM)
Merging v4l-dvb-next/master (3e238417254b media: nuvoton: VIDEO_NPCM_VCD_ECE should depend on ARCH_NPCM)
Merging pm/linux-next (742513f48261 Merge branch 'pm-cpufreq' into linux-next)
Merging cpufreq-arm/cpufreq/arm/linux-next (5b5b5806f223 cpufreq: qcom-nvmem: Introduce cpufreq for ipq95xx)
Merging cpupower/cpupower (6feb1a964119 cpupower: fix reference to nonexistent document)
Merging devfreq/devfreq-next (8f0cd531ee18 dt-bindings: devfreq: event: rockchip,dfi: Add rk3588 support)
Merging pmdomain/next (9e0cceadb7a5 pmdomain: Merge branch fixes into next)
Merging opp/opp/linux-next (5306fe37284c opp: ti: Use device_get_match_data())
Merging thermal/thermal/linux-next (9618efe343ea thermal/qcom/tsens: Drop ops_v0_1)
Merging dlm/next (eb53c01873ca MAINTAINERS: Update dlm maintainer and web page)
Merging rdma/for-next (2ef422f063b7 IB/mlx5: Fix init stage error handling to avoid double free of same QP and UAF)
Merging net-next/main (ff269e2cd5ad Merge tag 'net-next-6.7-followup' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next)
Merging bpf-next/for-next (ff269e2cd5ad Merge tag 'net-next-6.7-followup' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next)
Merging ipsec-next/master (eefed7662ff2 xfrm: policy: fix layer 4 flowi decoding)
Merging mlx5-next/mlx5-next (82f9378c443c net/mlx5: Handle IPsec steering upon master unbind/bind)
Merging netfilter-next/main (ef113733c288 bareudp: use ports to lookup route)
Merging ipvs-next/main (9cdee0634769 netfilter: nf_tables: Carry reset boolean in nft_set_dump_ctx)
Merging bluetooth/master (0783375f2c56 Bluetooth: ISO: Allow binding a PA sync socket)
Merging wireless-next/for-next (cc54d2e2c58a MAINTAINERS: Remove [email protected] mailing list)
Merging wpan-next/master (18b849f12dcc ieee802154: ca8210: Remove stray gpiod_unexport() call)
Merging wpan-staging/staging (18b849f12dcc ieee802154: ca8210: Remove stray gpiod_unexport() call)
Merging mtd/mtd/next (565fe150624e mtd: cfi_cmdset_0001: Byte swap OTP info)
Merging nand/nand/next (5a985960a4dd mtd: rawnand: meson: check return value of devm_kasprintf())
Merging spi-nor/spi-nor/next (6823a8383420 mtd: spi-nor: micron-st: use SFDP table for mt25qu512a)
Merging crypto/master (a312e07a65fb crypto: adiantum - flush destination page before unmapping)
Merging drm/drm-next (9ccde17d4655 Merge tag 'amd-drm-next-6.7-2023-11-03' of https://gitlab.freedesktop.org/agd5f/linux into drm-next)
CONFLICT (content): Merge conflict in drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
Merging drm-ci/topic/drm-ci (ad6bfe1b66a5 drm: ci: docs: fix build warning - add missing escape)
Merging drm-misc/for-linux-next (94565e95e247 drm/ssd130x: Fix possible uninitialized usage of crtc_state variable)
Merging amdgpu/drm-next (6d5e0032a92d drm/amd/display: Enable fast update on blendTF change)
Merging drm-intel/for-linux-next (9506fba463fc drm/i915/tc: Fix -Wformat-truncation in intel_tc_port_init)
Merging drm-tegra/for-next (2429b3c529da drm/tegra: Avoid potential 32-bit integer overflow)
Merging drm-msm/msm-next (b08d26dac1a1 drm/msm/a7xx: actually use a7xx state registers)
Merging drm-msm-lumag/msm-next-lumag (d3b4075b173f drm/msm/dp: use correct lifetime device for devm_drm_bridge_add)
Merging etnaviv/etnaviv/next (925b10728f20 drm/etnaviv: disable MLCG and pulse eater on GPU reset)
Merging fbdev/for-next (31b88945e0c8 fbdev: imsttfb: fix a resource leak in probe)
Merging regmap/for-next (f33804f1597d Merge remote-tracking branch 'regmap/for-6.6' into regmap-linus)
Merging sound/for-next (dc6e08b1a2ae ALSA: hda: cs35l41: Fix missing error code in cs35l41_smart_amp())
Merging ieee1394/for-next (c12d7aa7ffa4 firewire: Annotate struct fw_node with __counted_by)
Merging sound-asoc/for-next (4bdcbc31ad21 ASoC: dapm: fix clock get name)
Merging modules/modules-next (4652b8e4f3ff Merge tag '6.7-rc-ksmbd-server-fixes' of git://git.samba.org/ksmbd)
Merging input/next (28d3fe323547 Input: walkera0701 - use module_parport_driver macro to simplify the code)
Merging block/for-next (8aa6053114f3 Merge branch 'for-6.7/block' into for-next)
Merging device-mapper/for-next (9793c269da6c dm crypt: account large pages in cc->n_allocated_pages)
Merging libata/for-next (0e533cba3801 dt-bindings: ata: tegra: Disallow undefined properties)
Merging pcmcia/pcmcia-next (4f733de8b78a pcmcia: tcic: remove unneeded "&" in call to setup_timer())
Merging mmc/next (775d447cf0a7 Merge branch 'fixes' into next)
Merging mfd/for-mfd-next (2b481822446e mfd: lpc_ich: Mark *_gpio_offsets data with const)
Merging backlight/for-backlight-next (d5272d39995f dt-bindings: backlight: Add brightness-levels related common properties)
Merging battery/for-next (469d31745b9f power: reset: vexpress: Use device_get_match_data())
Merging regulator/for-next (8af4b4efdac9 Merge remote-tracking branch 'regulator/for-6.7' into regulator-next)
Merging security/next (e50856067289 lsm: fix a spelling mistake)
Merging apparmor/apparmor-next (6cede10161be apparmor: Fix some kernel-doc comments)
Merging integrity/next-integrity (b836c4d29f27 ima: detect changes to the backing overlay file)
Merging safesetid/safesetid-next (64b634830c91 LSM: SafeSetID: add setgroups() testing to selftest)
Merging selinux/next (f5bbdeda34c6 Automated merge of 'dev' into 'next')
Merging smack/next (3ad49d37cf57 smackfs: Prevent underflow in smk_set_cipso())
Merging tomoyo/master (0bb80ecc33a8 Linux 6.6-rc1)
Merging tpmdd/next (03acb9ccec3f keys: Remove unused extern declarations)
Merging watchdog/master (9d08e5909c81 dt-bindings: watchdog: Add support for Amlogic C3 and S4 SoCs)
Merging iommu/next (e8cca466a84a Merge branches 'iommu/fixes', 'arm/tegra', 'arm/smmu', 'virtio', 'x86/vt-d', 'x86/amd', 'core' and 's390' into next)
CONFLICT (content): Merge conflict in drivers/iommu/Kconfig
CONFLICT (content): Merge conflict in drivers/iommu/iommufd/selftest.c
CONFLICT (content): Merge conflict in include/linux/iommu.h
Merging audit/next (47846d51348d audit: don't take task_lock() in audit_exe_compare() code path)
Merging devicetree/for-next (fe612629746c dt-bindings: soc: fsl: cpm_qe: cpm1-scc-qmc: Add support for QMC HDLC)
Merging dt-krzk/for-next (d896029c9726 Merge branch 'next/dt64' into for-next)
Merging mailbox/mailbox-for-next (d09f466f71b6 dt-bindings: mailbox: qcom-ipcc: document the SM8650 Inter-Processor Communication Controller)
Merging spi/for-next (14c4fb111a39 Merge remote-tracking branch 'spi/for-6.6' into spi-linus)
Merging tip/master (e2e7af5cc8ab Merge branch into tip/master: 'x86/urgent')
Merging clockevents/timers/drivers/next (c28ca80ba3b5 clocksource: ep93xx: Add driver for Cirrus Logic EP93xx)
Merging edac/edac-for-next (6f15b178cd63 EDAC/versal: Add a Xilinx Versal memory controller driver)
Merging irqchip/irq/irqchip-next (19b5a44bee16 irqchip: Add support for Amlogic-C3 SoCs)
Merging ftrace/for-next (e1742fa172d5 Merge probes/for-next)
Merging rcu/rcu/next (7939f0d7b28c rcu: Restrict access to RCU CPU stall notifiers)
Merging kvm/next (45b890f7689e Merge tag 'kvmarm-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD)
Merging kvm-arm/next (123f42f0ad68 Merge branch kvm-arm64/pmu_pmcr_n into kvmarm/next)
Merging kvms390/next (70fea3019516 KVM: s390: add tracepoint in gmap notifier)
Merging kvm-ppc/topic/ppc-kvm (b7bce570430e powerpc/kvm: Force cast endianness of KVM shared regs)
Merging kvm-riscv/riscv_kvm_next (d9c00f44e5de KVM: riscv: selftests: Add SBI DBCN extension to get-reg-list test)
Merging kvm-x86/next (45b890f7689e Merge tag 'kvmarm-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD)
Merging xen-tip/linux-next (ebbf7f070078 acpi/processor: sanitize _OSC/_PDC capabilities for Xen dom0)
Merging percpu/for-next (3fcf62f24c80 Merge branch 'for-6.6' into for-next)
Merging workqueues/for-next (d5ce8f4ed90b Merge branch 'for-6.7' into for-next)
Merging drivers-x86/for-next (94ace9eda882 platform/x86: inspur-platform-profile: Add platform profile support)
Merging chrome-platform/for-next (47ea0ddb1f56 platform/chrome: cros_ec_lpc: Separate host command and irq disable)
Merging chrome-platform-firmware/for-firmware-next (0bb80ecc33a8 Linux 6.6-rc1)
Merging hsi/for-next (0bb80ecc33a8 Linux 6.6-rc1)
Merging leds/for-next (1b929c02afd3 Linux 6.2-rc1)
Merging leds-lj/for-leds-next (b9604be24158 leds: lp5521: Add an error check in lp5521_post_init_device)
Merging ipmi/for-next (bc3012f4e3a9 Merge tag 'v6.7-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging driver-core/driver-core-next (d2f51b3516da Merge tag 'rtc-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux)
Merging usb/usb-next (d2f51b3516da Merge tag 'rtc-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux)
Merging thunderbolt/next (a558892b3456 thunderbolt: Fix one kernel-doc comment)
Merging usb-serial/usb-next (8a749fd1a872 Linux 6.6-rc4)
Merging tty/tty-next (d2f51b3516da Merge tag 'rtc-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux)
Merging char-misc/char-misc-next (d2f51b3516da Merge tag 'rtc-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux)
Merging accel/habanalabs-next (631808095a82 Merge tag 'amd-drm-next-6.7-2023-10-27' of https://gitlab.freedesktop.org/agd5f/linux into drm-next)
Merging coresight/next (5ce62920de12 coresight: etm4x: Fix width of CCITMIN field)
Merging fastrpc/for-next (0bb80ecc33a8 Linux 6.6-rc1)
Merging fpga/for-next (d79eed22ba97 fpga: versal: Add support for 44-bit DMA operations)
Merging icc/icc-next (d4c720a19e9a Merge branch 'icc-platform-remove' into icc-next)
Merging iio/togreg (89e2233386a5 iio: proximity: sx9324: Switch to device_property_match_property_string())
Merging phy-next/next (d688c8264b8e phy: Remove duplicated include in phy-ralink-usb.c)
Merging soundwire/next (4ea2b6d3128e soundwire: dmi-quirks: update HP Omen match)
Merging extcon/extcon-next (b3edc3463d64 extcon: realtek: add the error handler for nvmem_cell_read)
Merging gnss/gnss-next (0bb80ecc33a8 Linux 6.6-rc1)
Merging vfio/next (2b88119e35b0 vfio/mtty: Enable migration support)
Merging w1/for-next (0bb80ecc33a8 Linux 6.6-rc1)
Merging staging/staging-next (d2f51b3516da Merge tag 'rtc-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux)
Merging counter-next/counter-next (7904cdf1397c counter: chrdev: remove a typo in header file comment)
Merging mux/for-next (44c026a73be8 Linux 6.4-rc3)
Merging dmaengine/next (03f25d53b145 dmaengine: stm32-mdma: correct desc prep when channel running)
Merging cgroup/for-next (b9a477034b11 Merge branch 'for-6.7' into for-next)
Merging scsi/for-next (88eed215d016 Merge branch 'misc' into for-next)
Merging scsi-mkp/for-next (a75a16c62a25 scsi: ufs: core: Leave space for 'Merging vhost/linux-next (e07754e0a1ea vhost-vdpa: fix use after free in vhost_vdpa_probe())
Merging rpmsg/for-next (6dc66a309673 Merge branches 'hwspinlock-next', 'rpmsg-next' and 'rproc-next' into for-next)
Merging gpio/for-next (0bb80ecc33a8 Linux 6.6-rc1)
Merging gpio-brgl/gpio/for-next (5be55473a064 pinctrl: tegra: drop the wrapper around pinctrl_gpio_request())
Merging gpio-intel/for-next (0bb80ecc33a8 Linux 6.6-rc1)
Merging pinctrl/for-next (63bffc2d3a99 pinctrl: Use device_get_match_data())
Merging pinctrl-intel/for-next (8d751da9f1d7 pinctrl: intel: fetch community only when we need it)
Merging pinctrl-renesas/renesas-pinctrl (583d80732055 pinctrl: renesas: rzn1: Convert to platform remove callback returning void)
Merging pinctrl-samsung/for-next (8aec97decfd0 pinctrl: samsung: do not offset pinctrl numberspaces)
Merging pwm/for-next (40592064a1a5 pwm: samsung: Document new member .channel in struct samsung_pwm_chip)
Merging userns/for-next (05bd6e0242b4 Merge of unpriv-ipc-sysctls-for-v6.2, and fix-atomic_lock_inc_below-for-v6.2 for testing in linux-next)
Merging ktest/for-next (7dc8e24f0e09 ktest: Restore stty setting at first in dodie)
Merging kselftest/next (5247e6dbed00 selftests/resctrl: Fix MBM test failure when MBA unavailable)
Merging kunit/test (0bb80ecc33a8 Linux 6.6-rc1)
Merging kunit-next/kunit (8040345fdae4 kunit: test: Fix the possible memory leak in executor_test)
Merging livepatching/for-next (602bf1830798 Merge branch 'for-6.7' into for-next)
Merging rtc/rtc-next (cfb67623ce28 dt-bindings: rtc: Add Mstar SSD202D RTC)
Merging nvdimm/libnvdimm-for-next (9ea459e477dc libnvdimm: remove kernel-doc warnings:)
Merging at24/at24/for-next (3774740fb221 eeprom: at24: add ST M24C64-D Additional Write lockable page support)
Merging ntb/ntb-next (9341b37ec17a ntb_perf: Fix printk format)
Merging seccomp/for-next/seccomp (31c65705a8cf perf/benchmark: fix seccomp_unotify benchmark for 32-bit)
Merging fsi/next (f04d61a379d6 fsi: fix some spelling mistakes in comment)
Merging slimbus/for-next (06c2afb862f9 Linux 6.5-rc1)
Merging nvmem/for-next (0bb80ecc33a8 Linux 6.6-rc1)
Merging xarray/main (2a15de80dd0f idr: fix param name in idr_alloc_cyclic() doc)
Merging hyperv/hyperv-next (ce9ecca0238b Linux 6.6-rc2)
Merging auxdisplay/auxdisplay (35b464e32c8b auxdisplay: hd44780: move cursor home after clear display command)
Merging kgdb/kgdb/for-next (23816724fdbd kdb: Corrects comment for kdballocenv)
Merging hmm/hmm (0bb80ecc33a8 Linux 6.6-rc1)
Merging cfi/cfi/next (06c2afb862f9 Linux 6.5-rc1)
Merging mhi/mhi-next (12606ba1d46b bus: mhi: ep: Do not allocate event ring element on stack)
Merging memblock/for-next (0f5e4adb608c memblock: report failures when memblock_can_resize is not set)
Merging cxl/next (5d09c63f11f0 cxl/hdm: Remove broken error path)
Merging zstd/zstd-next (2aa14b1ab2c4 zstd: import usptream v1.5.2)
Merging efi/next (5329aa5101f7 efivarfs: Add uid/gid mount options)
Merging unicode/for-next (b500d6d7243d unicode: Handle memory allocation failures in mkutf8data)
Merging slab/slab/for-next (90f055df1121 mm/slub: refactor calculate_order() and calc_slab_order())
Merging random/master (512dee0c00ad Merge tag 'x86-urgent-2023-01-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging landlock/next (f12f8f84509a selftests/landlock: Add tests for FS topology changes with network rules)
Merging rust/rust-next (3857af38e57a docs: rust: add "The Rust experiment" section)
Merging sysctl/sysctl-next (8b793bcda61f watchdog: move softlockup_panic back to early_param)
Merging execve/for-next/execve (21ca59b365c0 binfmt_misc: enable sandboxed mounts)
Merging bitmap/bitmap-for-next (bdcb37a5d8de buildid: reduce header file dependencies for module)
Merging hte/for-next (fc62d5e214df hte: Use kasprintf() instead of fixed buffer formatting)
Merging kspp/for-next/kspp (9cca73d7b4bf hwmon: (acpi_power_meter) replace open-coded kmemdup_nul)
Merging kspp-gustavo/for-next/kspp (4d8cbf6dbcda fs: omfs: Use flexible-array member in struct omfs_extent)
Merging nolibc/nolibc (0bb80ecc33a8 Linux 6.6-rc1)
Merging tsm/tsm-next (f4738f56d1dc virt: tdx-guest: Add Quote generation support using TSM_REPORTS)
Merging iommufd/for-next (b2b67c997bf7 iommufd: Organize the mock domain alloc functions closer to Joerg's tree)
On Tue, 2017-11-14 at 10:04 +0100, Michal Hocko wrote:
> If there is a general consensus that this is the preferred way to go,
> I
> will post the patch as an RFC to linux-api
>
> [1] http://lkml.kernel.org/r/[email protected]
> use.cz
I prefer the new flag. It is cleaner and avoids unintended breakage for
existing flag.
--
Khalid
From 1584035460514792667@xxx Tue Nov 14 10:05:34 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Tue 14-11-17 20:18:04, Michael Ellerman wrote:
> Michal Hocko <[email protected]> writes:
>
> > [Sorry for spamming, this one is the last attempt hopefully]
> >
> > On Mon 13-11-17 16:49:39, Michal Hocko wrote:
> >> On Mon 13-11-17 16:16:41, Michal Hocko wrote:
> >> > On Mon 13-11-17 13:00:57, Michal Hocko wrote:
> >> > [...]
> >> > > Yes, I have mentioned that in the previous email but the amount of code
> >> > > would be even larger. Basically every arch which reimplements
> >> > > arch_get_unmapped_area would have to special case new MAP_FIXED flag to
> >> > > do vma lookup.
> >> >
> >> > It turned out that this might be much more easier than I thought after
> >> > all. It seems we can really handle that in the common code. This would
> >> > mean that we are exposing a new functionality to the userspace though.
> >> > Myabe this would be useful on its own though. Just a quick draft (not
> >> > even compile tested) whether this makes sense in general. I would be
> >> > worried about unexpected behavior when somebody set other bit without a
> >> > good reason and we might fail with ENOMEM for such a call now.
> >>
> >> Hmm, the bigger problem would be the backward compatibility actually. We
> >> would get silent corruptions which is exactly what the flag is trying
> >> fix. mmap flags handling really sucks. So I guess we would have to make
> >> the flag internal only :/
> >
> > OK, so this one should take care of the backward compatibility while
> > still not touching the arch code
>
> I'm not sure I understand your worries about backward compatibility?
Just imagine you are running an application which uses the new flag
combination on an older kernel. You will get no warning, yet you have no
way to check that you have actually clobbered an existing mapping
because MAP_FIXED will be used the old way.
> If we add a new mmap flag which is currently unused then what is the
> problem? Are you worried about user code that accidentally passes that
> flag already?
If we add a completely new flag, like in this patch, then the code using
the flag will not clobber an existing mapping on older kernels which do
not recognize it (we will simply fall back to the default hint based
implementation). You might not get the mapping you asked for which sucks
but that is not fixable AFAICS. You can at least do
mapped_addr = mmap(addr, ... MAP_FIXED_SAFE...);
assert(mapped_addr == addr);
So I do not think we can go with the modifier unfortunatelly.
--
Michal Hocko
SUSE Labs
From 1584032639649608050@xxx Tue Nov 14 09:20:44 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
Michal Hocko <[email protected]> writes:
> [Sorry for spamming, this one is the last attempt hopefully]
>
> On Mon 13-11-17 16:49:39, Michal Hocko wrote:
>> On Mon 13-11-17 16:16:41, Michal Hocko wrote:
>> > On Mon 13-11-17 13:00:57, Michal Hocko wrote:
>> > [...]
>> > > Yes, I have mentioned that in the previous email but the amount of code
>> > > would be even larger. Basically every arch which reimplements
>> > > arch_get_unmapped_area would have to special case new MAP_FIXED flag to
>> > > do vma lookup.
>> >
>> > It turned out that this might be much more easier than I thought after
>> > all. It seems we can really handle that in the common code. This would
>> > mean that we are exposing a new functionality to the userspace though.
>> > Myabe this would be useful on its own though. Just a quick draft (not
>> > even compile tested) whether this makes sense in general. I would be
>> > worried about unexpected behavior when somebody set other bit without a
>> > good reason and we might fail with ENOMEM for such a call now.
>>
>> Hmm, the bigger problem would be the backward compatibility actually. We
>> would get silent corruptions which is exactly what the flag is trying
>> fix. mmap flags handling really sucks. So I guess we would have to make
>> the flag internal only :/
>
> OK, so this one should take care of the backward compatibility while
> still not touching the arch code
I'm not sure I understand your worries about backward compatibility?
If we add a new mmap flag which is currently unused then what is the
problem? Are you worried about user code that accidentally passes that
flag already?
> diff --git a/include/uapi/asm-generic/mman-common.h b/include/uapi/asm-generic/mman-common.h
> index 203268f9231e..03c518777f83 100644
> --- a/include/uapi/asm-generic/mman-common.h
> +++ b/include/uapi/asm-generic/mman-common.h
> @@ -25,6 +25,8 @@
> # define MAP_UNINITIALIZED 0x0 /* Don't support this flag */
> #endif
>
> +#define MAP_FIXED_SAFE 0x2000000 /* MAP_FIXED which doesn't unmap underlying mapping */
> +
As I said in my other mail I think this should be a modifier to
MAP_FIXED. That way all the existing code that checks for MAP_FIXED (in
the kernel) works exactly as it currently does - like the check Khalid
pointed out.
And I think MAP_NO_CLOBBER would be a better name.
cheers
From 1584031832000569643@xxx Tue Nov 14 09:07:54 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Tue 14-11-17 19:54:59, Michael Ellerman wrote:
> Michal Hocko <[email protected]> writes:
[...]
> > So this was the most simple solution I could come up
> > with. If there was a general interest for MAP_FIXED_SAFE then we can
> > introduce it later of course. I would just like the hardening merged
> > sooner rather than later.
>
> Sure. But in the scheme of things one more kernel release is not that
> big a deal to get it right. Given that the simple approach of dropping
> MAP_FIXED turns out to not be simple at all.
Well, my idea was to push this hardening to older kernels because those
were more vulnerable for the PIE base vs. stack placement and stack
controllable size from userspace etc... Anyway, as per [1] it seems that
the MAP_FIXED_SAFE doesn't look terrible from the backporting POV.
If there is a general consensus that this is the preferred way to go, I
will post the patch as an RFC to linux-api
[1] http://lkml.kernel.org/r/[email protected]
--
Michal Hocko
SUSE Labs
From 1584031632378699900@xxx Tue Nov 14 09:04:44 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
Michal Hocko <[email protected]> writes:
> On Mon 13-11-17 13:00:57, Michal Hocko wrote:
> [...]
>> Yes, I have mentioned that in the previous email but the amount of code
>> would be even larger. Basically every arch which reimplements
>> arch_get_unmapped_area would have to special case new MAP_FIXED flag to
>> do vma lookup.
>
> It turned out that this might be much more easier than I thought after
> all. It seems we can really handle that in the common code.
Ah nice. I should have read this before replying to your previous mail.
> This would mean that we are exposing a new functionality to the userspace though.
> Myabe this would be useful on its own though.
Yes I think it would. At least jemalloc seems like it could use it:
https://github.com/jemalloc/jemalloc/blob/9f455e2786685b443201c33119765c8093461174/src/pages.c#L65
And I have memories of some JIT code I read once which did a loop of
mmap()s or something to try and get allocations below 4GB or some other
limit - but I can't remember now what it was.
> Just a quick draft (not
> even compile tested) whether this makes sense in general. I would be
> worried about unexpected behavior when somebody set other bit without a
> good reason and we might fail with ENOMEM for such a call now.
>
> Elf loader would then use MAP_FIXED_SAFE rather than MAP_FIXED.
> ---
> diff --git a/arch/alpha/include/uapi/asm/mman.h b/arch/alpha/include/uapi/asm/mman.h
> index 3b26cc62dadb..d021c21f9b01 100644
> --- a/arch/alpha/include/uapi/asm/mman.h
> +++ b/arch/alpha/include/uapi/asm/mman.h
> @@ -31,6 +31,9 @@
> #define MAP_STACK 0x80000 /* give out an address that is best suited for process/thread stacks */
> #define MAP_HUGETLB 0x100000 /* create a huge page mapping */
>
> +#define MAP_KEEP_MAPPING 0x2000000
> +#define MAP_FIXED_SAFE MAP_FIXED|MAP_KEEP_MAPPING /* enforce MAP_FIXED without clobbering an existing mapping */
So bike-shedding a bit, but I think "SAFE" is too vague a name.
Perhaps MAP_NO_CLOBBER - which has the single semantic of "do not
clobber any existing mappings".
It would be a flag on its own, so you could pass it with or without
MAP_FIXED, but it would only change the behaviour when MAP_FIXED is
specified also.
cheers
From 1584031156652656318@xxx Tue Nov 14 08:57:10 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
Michal Hocko <[email protected]> writes:
> On Mon 13-11-17 22:34:50, Michael Ellerman wrote:
>> Hi Michal,
>>
>> Michal Hocko <[email protected]> writes:
>> > On Mon 13-11-17 10:20:06, Michal Hocko wrote:
>> >> [Cc arm and ppc maintainers]
>> >
>> > Hmm, it turned out to be a problem on other architectures as well.
>> > CCing more maintainers. For your reference, we are talking about
>> > http://lkml.kernel.org/r/[email protected]
>> > which has broken architectures which do apply aligning on the mmap
>> > address hint without MAP_FIXED applied. See below my proposed way
>> > around this issue because I belive that the above patch is quite
>> > valuable on its own to be dropped for all archs.
>>
>> I don't really like your solution sorry :) The fact that you've had to
>> patch seven arches seems like a red flag.
>>
>> I think this is a generic problem with MAP_FIXED, which I've heard
>> userspace folks complain about in the past.
>
> The thing is that we canno change MAP_FIXED behavior as it is carved in
> stone
Yes obviously. I didn't mean to imply we would change MAP_FIXED, rather
we would add a new flag with the new semantics.
>> Currently MAP_FIXED does two things:
>> 1. makes addr not a hint but the required address
>> 2. blasts any existing mapping
>>
>> You want 1) but not 2).
>
> + fail if there is a clashing range
Yep. I thought that was implied :)
>> So the right solution IMHO would be to add a new mmap flag to request
>> that behaviour, ie. a fixed address but iff there is nothing already
>> mapped there.
>>
>> I don't know the mm code well enough to know if that's hard for some
>> reason, but it *seems* like it should be doable.
>
> Yes, I have mentioned that in the previous email but the amount of code
> would be even larger. Basically every arch which reimplements
> arch_get_unmapped_area would have to special case new MAP_FIXED flag to
> do vma lookup.
I'd have to look, but my memory of the arch code is that it doesn't deal
with the vma so it wouldn't need any change.
> So this was the most simple solution I could come up
> with. If there was a general interest for MAP_FIXED_SAFE then we can
> introduce it later of course. I would just like the hardening merged
> sooner rather than later.
Sure. But in the scheme of things one more kernel release is not that
big a deal to get it right. Given that the simple approach of dropping
MAP_FIXED turns out to not be simple at all.
cheers
From 1584024423411111916@xxx Tue Nov 14 07:10:09 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Mon 13-11-17 09:35:22, Khalid Aziz wrote:
> On 11/13/2017 09:06 AM, Michal Hocko wrote:
> > OK, so this one should take care of the backward compatibility while
> > still not touching the arch code
> > ---
> > commit 39ff9bf8597e79a032da0954aea1f0d77d137765
> > Author: Michal Hocko <[email protected]>
> > Date: Mon Nov 13 17:06:24 2017 +0100
> >
> > mm: introduce MAP_FIXED_SAFE
> > MAP_FIXED is used quite often but it is inherently dangerous because it
> > unmaps an existing mapping covered by the requested range. While this
> > might be might be really desidered behavior in many cases there are
> > others which would rather see a failure than a silent memory corruption.
> > Introduce a new MAP_FIXED_SAFE flag for mmap to achive this behavior.
> > It is a MAP_FIXED extension with a single exception that it fails with
> > ENOMEM if the requested address is already covered by an existing
> > mapping. We still do rely on get_unmaped_area to handle all the arch
> > specific MAP_FIXED treatment and check for a conflicting vma after it
> > returns.
> > Signed-off-by: Michal Hocko <[email protected]>
> >
> > ...... deleted .......
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index 680506faceae..aad8d37f0205 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -1358,6 +1358,10 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
> > if (mm->map_count > sysctl_max_map_count)
> > return -ENOMEM;
> > + /* force arch specific MAP_FIXED handling in get_unmapped_area */
> > + if (flags & MAP_FIXED_SAFE)
> > + flags |= MAP_FIXED;
> > +
> > /* Obtain the address to map to. we verify (or select) it and ensure
> > * that it represents a valid section of the address space.
> > */
>
> Do you need to move this code above:
>
> if (!(flags & MAP_FIXED))
> addr = round_hint_to_min(addr);
>
> /* Careful about overflows.. */
> len = PAGE_ALIGN(len);
> if (!len)
> return -ENOMEM;
>
> Not doing that might mean the hint address will end up being rounded for
> MAP_FIXED_SAFE which would change the behavior from MAP_FIXED.
Yes, I will move it.
--
Michal Hocko
SUSE Labs
From 1583999917533601435@xxx Tue Nov 14 00:40:38 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
Hi Andrew,
On Mon, 13 Nov 2017 16:03:14 -0800 Andrew Morton <[email protected]> wrote:
>
> Does this kernel have "fs/binfmt_elf.c: drop MAP_FIXED usage from
> elf_map" applied? That patch was dropped due to runtime issues.
next-20171107 has that patch in it, next-20171108 does not.
--
Cheers,
Stephen Rothwell
From 1583997630682050362@xxx Tue Nov 14 00:04:17 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Sun, 12 Nov 2017 11:38:02 +1030 Joel Stanley <[email protected]> wrote:
> On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko <[email protected]> wrote:
> > Hi Joel,
> >
> > On Wed 08-11-17 15:20:50, Michal Hocko wrote:
> > [...]
> >> > There are a lot of messages on the way up that look like this:
> >> >
> >> > [ 2.527460] Uhuuh, elf segement at 000d9000 requested but the
> >> > memory is mapped already
> >> > [ 2.540160] Uhuuh, elf segement at 000d9000 requested but the
> >> > memory is mapped already
> >> > [ 2.546153] Uhuuh, elf segement at 000d9000 requested but the
> >> > memory is mapped already
> >> >
> >> > And then trying to run userspace looks like this:
> >>
> >> Could you please run with debugging patch posted
> >> http://lkml.kernel.org/r/[email protected]
> >
> > Did you have chance to test with this debugging patch, please?
>
> Lots of this:
>
> [ 1.177266] Uhuuh, elf segement at 000d9000 requested but the
> memory is mapped already, got 000dd000
> [ 1.177555] Clashing vma [dd000, de000] flags:100873 name:(null)
>
> Full log is attached.
>
> If you want to reproduce yourself and have an arm compiler lying around:
>
> $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make aspeed_g5_defconfig
> $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make
> $ qemu-system-arm -M ast2500-evb -nographic -nodefaults -serial stdio \
> -kernel arch/arm/boot/zImage \
> -dtb arch/arm/boot/dts/aspeed-ast2500-evb.dtb
>
> I'm using Qemu 2.10 which current distros ship. ymmv with older releases.
(wakes up)
Does this kernel have "fs/binfmt_elf.c: drop MAP_FIXED usage from
elf_map" applied? That patch was dropped due to runtime issues.
From 1583969580354767759@xxx Mon Nov 13 16:38:26 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On 11/13/2017 09:06 AM, Michal Hocko wrote:
> OK, so this one should take care of the backward compatibility while
> still not touching the arch code
> ---
> commit 39ff9bf8597e79a032da0954aea1f0d77d137765
> Author: Michal Hocko <[email protected]>
> Date: Mon Nov 13 17:06:24 2017 +0100
>
> mm: introduce MAP_FIXED_SAFE
>
> MAP_FIXED is used quite often but it is inherently dangerous because it
> unmaps an existing mapping covered by the requested range. While this
> might be might be really desidered behavior in many cases there are
> others which would rather see a failure than a silent memory corruption.
> Introduce a new MAP_FIXED_SAFE flag for mmap to achive this behavior.
> It is a MAP_FIXED extension with a single exception that it fails with
> ENOMEM if the requested address is already covered by an existing
> mapping. We still do rely on get_unmaped_area to handle all the arch
> specific MAP_FIXED treatment and check for a conflicting vma after it
> returns.
>
> Signed-off-by: Michal Hocko <[email protected]>
>
> ...... deleted .......
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 680506faceae..aad8d37f0205 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1358,6 +1358,10 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
> if (mm->map_count > sysctl_max_map_count)
> return -ENOMEM;
>
> + /* force arch specific MAP_FIXED handling in get_unmapped_area */
> + if (flags & MAP_FIXED_SAFE)
> + flags |= MAP_FIXED;
> +
> /* Obtain the address to map to. we verify (or select) it and ensure
> * that it represents a valid section of the address space.
> */
Do you need to move this code above:
if (!(flags & MAP_FIXED))
addr = round_hint_to_min(addr);
/* Careful about overflows.. */
len = PAGE_ALIGN(len);
if (!len)
return -ENOMEM;
Not doing that might mean the hint address will end up being rounded for
MAP_FIXED_SAFE which would change the behavior from MAP_FIXED.
--
Khalid
From 1583967638937488736@xxx Mon Nov 13 16:07:35 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
[Sorry for spamming, this one is the last attempt hopefully]
On Mon 13-11-17 16:49:39, Michal Hocko wrote:
> On Mon 13-11-17 16:16:41, Michal Hocko wrote:
> > On Mon 13-11-17 13:00:57, Michal Hocko wrote:
> > [...]
> > > Yes, I have mentioned that in the previous email but the amount of code
> > > would be even larger. Basically every arch which reimplements
> > > arch_get_unmapped_area would have to special case new MAP_FIXED flag to
> > > do vma lookup.
> >
> > It turned out that this might be much more easier than I thought after
> > all. It seems we can really handle that in the common code. This would
> > mean that we are exposing a new functionality to the userspace though.
> > Myabe this would be useful on its own though. Just a quick draft (not
> > even compile tested) whether this makes sense in general. I would be
> > worried about unexpected behavior when somebody set other bit without a
> > good reason and we might fail with ENOMEM for such a call now.
>
> Hmm, the bigger problem would be the backward compatibility actually. We
> would get silent corruptions which is exactly what the flag is trying
> fix. mmap flags handling really sucks. So I guess we would have to make
> the flag internal only :/
OK, so this one should take care of the backward compatibility while
still not touching the arch code
---
commit 39ff9bf8597e79a032da0954aea1f0d77d137765
Author: Michal Hocko <[email protected]>
Date: Mon Nov 13 17:06:24 2017 +0100
mm: introduce MAP_FIXED_SAFE
MAP_FIXED is used quite often but it is inherently dangerous because it
unmaps an existing mapping covered by the requested range. While this
might be might be really desidered behavior in many cases there are
others which would rather see a failure than a silent memory corruption.
Introduce a new MAP_FIXED_SAFE flag for mmap to achive this behavior.
It is a MAP_FIXED extension with a single exception that it fails with
ENOMEM if the requested address is already covered by an existing
mapping. We still do rely on get_unmaped_area to handle all the arch
specific MAP_FIXED treatment and check for a conflicting vma after it
returns.
Signed-off-by: Michal Hocko <[email protected]>
diff --git a/arch/alpha/include/uapi/asm/mman.h b/arch/alpha/include/uapi/asm/mman.h
index 3b26cc62dadb..767bcb8a4c28 100644
--- a/arch/alpha/include/uapi/asm/mman.h
+++ b/arch/alpha/include/uapi/asm/mman.h
@@ -31,6 +31,8 @@
#define MAP_STACK 0x80000 /* give out an address that is best suited for process/thread stacks */
#define MAP_HUGETLB 0x100000 /* create a huge page mapping */
+#define MAP_FIXED_SAFE 0x2000000 /* MAP_FIXED which doesn't unmap underlying mapping */
+
#define MS_ASYNC 1 /* sync memory asynchronously */
#define MS_SYNC 2 /* synchronous memory sync */
#define MS_INVALIDATE 4 /* invalidate the caches */
diff --git a/arch/mips/include/uapi/asm/mman.h b/arch/mips/include/uapi/asm/mman.h
index da3216007fe0..c2311eb7219b 100644
--- a/arch/mips/include/uapi/asm/mman.h
+++ b/arch/mips/include/uapi/asm/mman.h
@@ -49,6 +49,8 @@
#define MAP_STACK 0x40000 /* give out an address that is best suited for process/thread stacks */
#define MAP_HUGETLB 0x80000 /* create a huge page mapping */
+#define MAP_FIXED_SAFE 0x2000000 /* MAP_FIXED which doesn't unmap underlying mapping */
+
/*
* Flags for msync
*/
diff --git a/arch/parisc/include/uapi/asm/mman.h b/arch/parisc/include/uapi/asm/mman.h
index cc9ba1d34779..b06fd830bc6f 100644
--- a/arch/parisc/include/uapi/asm/mman.h
+++ b/arch/parisc/include/uapi/asm/mman.h
@@ -25,6 +25,8 @@
#define MAP_STACK 0x40000 /* give out an address that is best suited for process/thread stacks */
#define MAP_HUGETLB 0x80000 /* create a huge page mapping */
+#define MAP_FIXED_SAFE 0x2000000 /* MAP_FIXED which doesn't unmap underlying mapping */
+
#define MS_SYNC 1 /* synchronous memory sync */
#define MS_ASYNC 2 /* sync memory asynchronously */
#define MS_INVALIDATE 4 /* invalidate the caches */
diff --git a/arch/xtensa/include/uapi/asm/mman.h b/arch/xtensa/include/uapi/asm/mman.h
index b15b278aa314..f4b291bca764 100644
--- a/arch/xtensa/include/uapi/asm/mman.h
+++ b/arch/xtensa/include/uapi/asm/mman.h
@@ -62,6 +62,8 @@
# define MAP_UNINITIALIZED 0x0 /* Don't support this flag */
#endif
+#define MAP_FIXED_SAFE 0x2000000 /* MAP_FIXED which doesn't unmap underlying mapping */
+
/*
* Flags for msync
*/
diff --git a/include/uapi/asm-generic/mman-common.h b/include/uapi/asm-generic/mman-common.h
index 203268f9231e..03c518777f83 100644
--- a/include/uapi/asm-generic/mman-common.h
+++ b/include/uapi/asm-generic/mman-common.h
@@ -25,6 +25,8 @@
# define MAP_UNINITIALIZED 0x0 /* Don't support this flag */
#endif
+#define MAP_FIXED_SAFE 0x2000000 /* MAP_FIXED which doesn't unmap underlying mapping */
+
/*
* Flags for mlock
*/
diff --git a/mm/mmap.c b/mm/mmap.c
index 680506faceae..aad8d37f0205 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1358,6 +1358,10 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
if (mm->map_count > sysctl_max_map_count)
return -ENOMEM;
+ /* force arch specific MAP_FIXED handling in get_unmapped_area */
+ if (flags & MAP_FIXED_SAFE)
+ flags |= MAP_FIXED;
+
/* Obtain the address to map to. we verify (or select) it and ensure
* that it represents a valid section of the address space.
*/
@@ -1365,6 +1369,13 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
if (offset_in_page(addr))
return addr;
+ if (flags & MAP_FIXED_SAFE) {
+ struct vm_area_struct *vma = find_vma(mm, addr);
+
+ if (vma && vma->vm_start <= addr)
+ return -ENOMEM;
+ }
+
if (prot == PROT_EXEC) {
pkey = execute_only_pkey(mm);
if (pkey < 0)
--
Michal Hocko
SUSE Labs
From 1583967250067052083@xxx Mon Nov 13 16:01:24 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Mon 13-11-17 15:48:13, Russell King - ARM Linux wrote:
> On Mon, Nov 13, 2017 at 04:16:41PM +0100, Michal Hocko wrote:
> > On Mon 13-11-17 13:00:57, Michal Hocko wrote:
> > [...]
> > > Yes, I have mentioned that in the previous email but the amount of code
> > > would be even larger. Basically every arch which reimplements
> > > arch_get_unmapped_area would have to special case new MAP_FIXED flag to
> > > do vma lookup.
> >
> > It turned out that this might be much more easier than I thought after
> > all. It seems we can really handle that in the common code. This would
> > mean that we are exposing a new functionality to the userspace though.
> > Myabe this would be useful on its own though. Just a quick draft (not
> > even compile tested) whether this makes sense in general. I would be
> > worried about unexpected behavior when somebody set other bit without a
> > good reason and we might fail with ENOMEM for such a call now.
> >
> > Elf loader would then use MAP_FIXED_SAFE rather than MAP_FIXED.
> > ---
> > diff --git a/arch/alpha/include/uapi/asm/mman.h b/arch/alpha/include/uapi/asm/mman.h
> > index 3b26cc62dadb..d021c21f9b01 100644
> > --- a/arch/alpha/include/uapi/asm/mman.h
> > +++ b/arch/alpha/include/uapi/asm/mman.h
> > @@ -31,6 +31,9 @@
> > #define MAP_STACK 0x80000 /* give out an address that is best suited for process/thread stacks */
> > #define MAP_HUGETLB 0x100000 /* create a huge page mapping */
> >
> > +#define MAP_KEEP_MAPPING 0x2000000
> > +#define MAP_FIXED_SAFE MAP_FIXED|MAP_KEEP_MAPPING /* enforce MAP_FIXED without clobbering an existing mapping */
>
> A few things...
>
> 1. Does this need to be exposed to userland?
As I've written in another email, exposing the flag this way would be
really dangerous wrt. backward compatibility. So we would either need some
translation or make it a flag on its own and touch the arch specific
code which I really wanted to prevent from.
Whether this is something useful for the userspace is a separate
question which I should bring up to linux-api for a wider audience to
discuss.
So I guess this goes down to whether we want/need something like
MAP_FIXED_SAFE or opt out the specific hardening code for arches that
cannot make unaligned mappings for the requested address.
> 2. Can it end up in include/uapi/asm-generic/mman*.h ?
> 3. The definition of MAP_FIXED_SAFE should really have parens around it.
Of course. I thought I did...
> > @@ -1365,6 +1365,13 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
> > if (offset_in_page(addr))
> > return addr;
> >
> > + if ((flags & MAP_FIXED_SAFE) == MAP_FIXED_SAFE) {
>
> I'm surprised this doesn't warn - since this effectively expands to:
>
> flags & MAP_FIXED | MAP_KEEP_MAPPING
>
> hence why MAP_FIXED_SAFE needs parens.
It sure does.
Thanks!
--
Michal Hocko
SUSE Labs
From 1583966660825090133@xxx Mon Nov 13 15:52:02 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Mon 13-11-17 16:16:41, Michal Hocko wrote:
> On Mon 13-11-17 13:00:57, Michal Hocko wrote:
> [...]
> > Yes, I have mentioned that in the previous email but the amount of code
> > would be even larger. Basically every arch which reimplements
> > arch_get_unmapped_area would have to special case new MAP_FIXED flag to
> > do vma lookup.
>
> It turned out that this might be much more easier than I thought after
> all. It seems we can really handle that in the common code. This would
> mean that we are exposing a new functionality to the userspace though.
> Myabe this would be useful on its own though. Just a quick draft (not
> even compile tested) whether this makes sense in general. I would be
> worried about unexpected behavior when somebody set other bit without a
> good reason and we might fail with ENOMEM for such a call now.
Hmm, the bigger problem would be the backward compatibility actually. We
would get silent corruptions which is exactly what the flag is trying
fix. mmap flags handling really sucks. So I guess we would have to make
the flag internal only :/
--
Michal Hocko
SUSE Labs
From 1583966498711182071@xxx Mon Nov 13 15:49:27 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Mon, Nov 13, 2017 at 04:16:41PM +0100, Michal Hocko wrote:
> On Mon 13-11-17 13:00:57, Michal Hocko wrote:
> [...]
> > Yes, I have mentioned that in the previous email but the amount of code
> > would be even larger. Basically every arch which reimplements
> > arch_get_unmapped_area would have to special case new MAP_FIXED flag to
> > do vma lookup.
>
> It turned out that this might be much more easier than I thought after
> all. It seems we can really handle that in the common code. This would
> mean that we are exposing a new functionality to the userspace though.
> Myabe this would be useful on its own though. Just a quick draft (not
> even compile tested) whether this makes sense in general. I would be
> worried about unexpected behavior when somebody set other bit without a
> good reason and we might fail with ENOMEM for such a call now.
>
> Elf loader would then use MAP_FIXED_SAFE rather than MAP_FIXED.
> ---
> diff --git a/arch/alpha/include/uapi/asm/mman.h b/arch/alpha/include/uapi/asm/mman.h
> index 3b26cc62dadb..d021c21f9b01 100644
> --- a/arch/alpha/include/uapi/asm/mman.h
> +++ b/arch/alpha/include/uapi/asm/mman.h
> @@ -31,6 +31,9 @@
> #define MAP_STACK 0x80000 /* give out an address that is best suited for process/thread stacks */
> #define MAP_HUGETLB 0x100000 /* create a huge page mapping */
>
> +#define MAP_KEEP_MAPPING 0x2000000
> +#define MAP_FIXED_SAFE MAP_FIXED|MAP_KEEP_MAPPING /* enforce MAP_FIXED without clobbering an existing mapping */
A few things...
1. Does this need to be exposed to userland?
2. Can it end up in include/uapi/asm-generic/mman*.h ?
3. The definition of MAP_FIXED_SAFE should really have parens around it.
> @@ -1365,6 +1365,13 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
> if (offset_in_page(addr))
> return addr;
>
> + if ((flags & MAP_FIXED_SAFE) == MAP_FIXED_SAFE) {
I'm surprised this doesn't warn - since this effectively expands to:
flags & MAP_FIXED | MAP_KEEP_MAPPING
hence why MAP_FIXED_SAFE needs parens.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
From 1583965440933608705@xxx Mon Nov 13 15:32:39 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Mon 13-11-17 15:09:09, Russell King - ARM Linux wrote:
> On Mon, Nov 13, 2017 at 03:11:40PM +0100, Michal Hocko wrote:
> > On Mon 13-11-17 10:20:06, Michal Hocko wrote:
> > > [Cc arm and ppc maintainers]
> > >
> > > Thanks a lot for testing!
> > >
> > > On Sun 12-11-17 11:38:02, Joel Stanley wrote:
> > > > On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko <[email protected]> wrote:
> > > > > Hi Joel,
> > > > >
> > > > > On Wed 08-11-17 15:20:50, Michal Hocko wrote:
> > > > > [...]
> > > > >> > There are a lot of messages on the way up that look like this:
> > > > >> >
> > > > >> > [ 2.527460] Uhuuh, elf segement at 000d9000 requested but the
> > > > >> > memory is mapped already
> > > > >> > [ 2.540160] Uhuuh, elf segement at 000d9000 requested but the
> > > > >> > memory is mapped already
> > > > >> > [ 2.546153] Uhuuh, elf segement at 000d9000 requested but the
> > > > >> > memory is mapped already
> > > > >> >
> > > > >> > And then trying to run userspace looks like this:
> > > > >>
> > > > >> Could you please run with debugging patch posted
> > > > >> http://lkml.kernel.org/r/[email protected]
> > > > >
> > > > > Did you have chance to test with this debugging patch, please?
> > > >
> > > > Lots of this:
> > > >
> > > > [ 1.177266] Uhuuh, elf segement at 000d9000 requested but the memory is mapped already, got 000dd000
> > > > [ 1.177555] Clashing vma [dd000, de000] flags:100873 name:(null)
> > >
> > > This smells like the problem I've expected that mmap with hint doesn't
> > > respect the hint even though there is no clashing mapping. The above
> > > basically says that we didn't map at 0xd9000 but it has placed it at
> > > 0xdd000. The nearest (clashing) vma is at 0xdd000 so this is our new
> > > mapping. find_vma returns the closest vma (with addr < vm_end) for the
> > > given address 0xd9000 so this address cannot be mapped by any other vma.
> > >
> > > Now that I am looking at arm's arch_get_unmapped_area it does perform
> > > aligning for shared vmas.
> >
> > Sorry for confusion here. These are not shared mappings as pointed out
> > by Russell in a private email. I got confused by the above flags which I
> > have misinterpreted as bit 0 set => MAP_SHARED. These are vm_flags
> > obviously so the bit 0 is VM_READ. Sorry about the confusion. The real
> > reason we are doing the alignment is that we do a file mapping
> > /*
> > * We only need to do colour alignment if either the I or D
> > * caches alias.
> > */
> > if (aliasing)
> > do_align = filp || (flags & MAP_SHARED);
> >
> > I am not really familiar with this architecture to understand why do we
> > need aliasing for file mappings, though.
>
> I think it's there so that flush_dcache_page() works - possibly
> get_user_pages() being used on a private mapping of page cache pages,
> but that's guessing.
I fail to see how the mixure of MAP_FIXED and regular mapping of the
same file work then, but as I've said I really do not understand this
code.
> I'm afraid I don't remember all the details, this is code from around
> 15 years ago, and I'd be very nervous about changing it now without
> fully understanding the issues.
Ohh, absolutely! I didn't dare to touch this code and that's why I took
the easy way and simply opt-out from the harding for all those archs
that are basically sharing this pattern. But after a closer look it
seems that we can really introduce MAP_FIXED_SAFE that would keep the
arch mmap code intact yet we would get the hardening for all archs.
It would allow also allow a safer MAP_FIXED semantic for userspace.
--
Michal Hocko
SUSE Labs
From 1583964557224138598@xxx Mon Nov 13 15:18:36 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Mon 13-11-17 13:00:57, Michal Hocko wrote:
[...]
> Yes, I have mentioned that in the previous email but the amount of code
> would be even larger. Basically every arch which reimplements
> arch_get_unmapped_area would have to special case new MAP_FIXED flag to
> do vma lookup.
It turned out that this might be much more easier than I thought after
all. It seems we can really handle that in the common code. This would
mean that we are exposing a new functionality to the userspace though.
Myabe this would be useful on its own though. Just a quick draft (not
even compile tested) whether this makes sense in general. I would be
worried about unexpected behavior when somebody set other bit without a
good reason and we might fail with ENOMEM for such a call now.
Elf loader would then use MAP_FIXED_SAFE rather than MAP_FIXED.
---
diff --git a/arch/alpha/include/uapi/asm/mman.h b/arch/alpha/include/uapi/asm/mman.h
index 3b26cc62dadb..d021c21f9b01 100644
--- a/arch/alpha/include/uapi/asm/mman.h
+++ b/arch/alpha/include/uapi/asm/mman.h
@@ -31,6 +31,9 @@
#define MAP_STACK 0x80000 /* give out an address that is best suited for process/thread stacks */
#define MAP_HUGETLB 0x100000 /* create a huge page mapping */
+#define MAP_KEEP_MAPPING 0x2000000
+#define MAP_FIXED_SAFE MAP_FIXED|MAP_KEEP_MAPPING /* enforce MAP_FIXED without clobbering an existing mapping */
+
#define MS_ASYNC 1 /* sync memory asynchronously */
#define MS_SYNC 2 /* synchronous memory sync */
#define MS_INVALIDATE 4 /* invalidate the caches */
diff --git a/arch/mips/include/uapi/asm/mman.h b/arch/mips/include/uapi/asm/mman.h
index da3216007fe0..51e3885fbfc1 100644
--- a/arch/mips/include/uapi/asm/mman.h
+++ b/arch/mips/include/uapi/asm/mman.h
@@ -49,6 +49,9 @@
#define MAP_STACK 0x40000 /* give out an address that is best suited for process/thread stacks */
#define MAP_HUGETLB 0x80000 /* create a huge page mapping */
+#define MAP_KEEP_MAPPING 0x2000000
+#define MAP_FIXED_SAFE MAP_FIXED|MAP_KEEP_MAPPING /* enforce MAP_FIXED without clobbering an existing mapping */
+
/*
* Flags for msync
*/
diff --git a/arch/parisc/include/uapi/asm/mman.h b/arch/parisc/include/uapi/asm/mman.h
index cc9ba1d34779..5a4381484fc5 100644
--- a/arch/parisc/include/uapi/asm/mman.h
+++ b/arch/parisc/include/uapi/asm/mman.h
@@ -25,6 +25,9 @@
#define MAP_STACK 0x40000 /* give out an address that is best suited for process/thread stacks */
#define MAP_HUGETLB 0x80000 /* create a huge page mapping */
+#define MAP_KEEP_MAPPING 0x2000000
+#define MAP_FIXED_SAFE MAP_FIXED|MAP_KEEP_MAPPING /* enforce MAP_FIXED without clobbering an existing mapping */
+
#define MS_SYNC 1 /* synchronous memory sync */
#define MS_ASYNC 2 /* sync memory asynchronously */
#define MS_INVALIDATE 4 /* invalidate the caches */
diff --git a/arch/xtensa/include/uapi/asm/mman.h b/arch/xtensa/include/uapi/asm/mman.h
index b15b278aa314..5df8a81524da 100644
--- a/arch/xtensa/include/uapi/asm/mman.h
+++ b/arch/xtensa/include/uapi/asm/mman.h
@@ -62,6 +62,9 @@
# define MAP_UNINITIALIZED 0x0 /* Don't support this flag */
#endif
+#define MAP_KEEP_MAPPING 0x2000000
+#define MAP_FIXED_SAFE MAP_FIXED|MAP_KEEP_MAPPING /* enforce MAP_FIXED without clobbering an existing mapping */
+
/*
* Flags for msync
*/
diff --git a/include/uapi/asm-generic/mman-common.h b/include/uapi/asm-generic/mman-common.h
index 203268f9231e..22442846f5c8 100644
--- a/include/uapi/asm-generic/mman-common.h
+++ b/include/uapi/asm-generic/mman-common.h
@@ -25,6 +25,9 @@
# define MAP_UNINITIALIZED 0x0 /* Don't support this flag */
#endif
+#define MAP_KEEP_MAPPING 0x2000000
+#define MAP_FIXED_SAFE MAP_FIXED|MAP_KEEP_MAPPING /* enforce MAP_FIXED without clobbering an existing mapping */
+
/*
* Flags for mlock
*/
diff --git a/mm/mmap.c b/mm/mmap.c
index 680506faceae..e53b6b15a8d9 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1365,6 +1365,13 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
if (offset_in_page(addr))
return addr;
+ if ((flags & MAP_FIXED_SAFE) == MAP_FIXED_SAFE) {
+ struct vm_area_struct *vma = find_vma(mm, addr);
+
+ if (vma && vma->vm_start <= addr)
+ return -ENOMEM;
+ }
+
if (prot == PROT_EXEC) {
pkey = execute_only_pkey(mm);
if (pkey < 0)
--
Michal Hocko
SUSE Labs
From 1583964071696893637@xxx Mon Nov 13 15:10:53 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Mon, Nov 13, 2017 at 03:11:40PM +0100, Michal Hocko wrote:
> On Mon 13-11-17 10:20:06, Michal Hocko wrote:
> > [Cc arm and ppc maintainers]
> >
> > Thanks a lot for testing!
> >
> > On Sun 12-11-17 11:38:02, Joel Stanley wrote:
> > > On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko <[email protected]> wrote:
> > > > Hi Joel,
> > > >
> > > > On Wed 08-11-17 15:20:50, Michal Hocko wrote:
> > > > [...]
> > > >> > There are a lot of messages on the way up that look like this:
> > > >> >
> > > >> > [ 2.527460] Uhuuh, elf segement at 000d9000 requested but the
> > > >> > memory is mapped already
> > > >> > [ 2.540160] Uhuuh, elf segement at 000d9000 requested but the
> > > >> > memory is mapped already
> > > >> > [ 2.546153] Uhuuh, elf segement at 000d9000 requested but the
> > > >> > memory is mapped already
> > > >> >
> > > >> > And then trying to run userspace looks like this:
> > > >>
> > > >> Could you please run with debugging patch posted
> > > >> http://lkml.kernel.org/r/[email protected]
> > > >
> > > > Did you have chance to test with this debugging patch, please?
> > >
> > > Lots of this:
> > >
> > > [ 1.177266] Uhuuh, elf segement at 000d9000 requested but the memory is mapped already, got 000dd000
> > > [ 1.177555] Clashing vma [dd000, de000] flags:100873 name:(null)
> >
> > This smells like the problem I've expected that mmap with hint doesn't
> > respect the hint even though there is no clashing mapping. The above
> > basically says that we didn't map at 0xd9000 but it has placed it at
> > 0xdd000. The nearest (clashing) vma is at 0xdd000 so this is our new
> > mapping. find_vma returns the closest vma (with addr < vm_end) for the
> > given address 0xd9000 so this address cannot be mapped by any other vma.
> >
> > Now that I am looking at arm's arch_get_unmapped_area it does perform
> > aligning for shared vmas.
>
> Sorry for confusion here. These are not shared mappings as pointed out
> by Russell in a private email. I got confused by the above flags which I
> have misinterpreted as bit 0 set => MAP_SHARED. These are vm_flags
> obviously so the bit 0 is VM_READ. Sorry about the confusion. The real
> reason we are doing the alignment is that we do a file mapping
> /*
> * We only need to do colour alignment if either the I or D
> * caches alias.
> */
> if (aliasing)
> do_align = filp || (flags & MAP_SHARED);
>
> I am not really familiar with this architecture to understand why do we
> need aliasing for file mappings, though.
I think it's there so that flush_dcache_page() works - possibly
get_user_pages() being used on a private mapping of page cache pages,
but that's guessing.
I'm afraid I don't remember all the details, this is code from around
15 years ago, and I'd be very nervous about changing it now without
fully understanding the issues.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
From 1583960474934681864@xxx Mon Nov 13 14:13:43 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Mon 13-11-17 10:20:06, Michal Hocko wrote:
> [Cc arm and ppc maintainers]
>
> Thanks a lot for testing!
>
> On Sun 12-11-17 11:38:02, Joel Stanley wrote:
> > On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko <[email protected]> wrote:
> > > Hi Joel,
> > >
> > > On Wed 08-11-17 15:20:50, Michal Hocko wrote:
> > > [...]
> > >> > There are a lot of messages on the way up that look like this:
> > >> >
> > >> > [ 2.527460] Uhuuh, elf segement at 000d9000 requested but the
> > >> > memory is mapped already
> > >> > [ 2.540160] Uhuuh, elf segement at 000d9000 requested but the
> > >> > memory is mapped already
> > >> > [ 2.546153] Uhuuh, elf segement at 000d9000 requested but the
> > >> > memory is mapped already
> > >> >
> > >> > And then trying to run userspace looks like this:
> > >>
> > >> Could you please run with debugging patch posted
> > >> http://lkml.kernel.org/r/[email protected]
> > >
> > > Did you have chance to test with this debugging patch, please?
> >
> > Lots of this:
> >
> > [ 1.177266] Uhuuh, elf segement at 000d9000 requested but the memory is mapped already, got 000dd000
> > [ 1.177555] Clashing vma [dd000, de000] flags:100873 name:(null)
>
> This smells like the problem I've expected that mmap with hint doesn't
> respect the hint even though there is no clashing mapping. The above
> basically says that we didn't map at 0xd9000 but it has placed it at
> 0xdd000. The nearest (clashing) vma is at 0xdd000 so this is our new
> mapping. find_vma returns the closest vma (with addr < vm_end) for the
> given address 0xd9000 so this address cannot be mapped by any other vma.
>
> Now that I am looking at arm's arch_get_unmapped_area it does perform
> aligning for shared vmas.
Sorry for confusion here. These are not shared mappings as pointed out
by Russell in a private email. I got confused by the above flags which I
have misinterpreted as bit 0 set => MAP_SHARED. These are vm_flags
obviously so the bit 0 is VM_READ. Sorry about the confusion. The real
reason we are doing the alignment is that we do a file mapping
/*
* We only need to do colour alignment if either the I or D
* caches alias.
*/
if (aliasing)
do_align = filp || (flags & MAP_SHARED);
I am not really familiar with this architecture to understand why do we
need aliasing for file mappings, though.
--
Michal Hocko
SUSE Labs
From 1583952188245522677@xxx Mon Nov 13 12:02:00 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Mon 13-11-17 22:34:50, Michael Ellerman wrote:
> Hi Michal,
>
> Michal Hocko <[email protected]> writes:
> > On Mon 13-11-17 10:20:06, Michal Hocko wrote:
> >> [Cc arm and ppc maintainers]
> >
> > Hmm, it turned out to be a problem on other architectures as well.
> > CCing more maintainers. For your reference, we are talking about
> > http://lkml.kernel.org/r/[email protected]
> > which has broken architectures which do apply aligning on the mmap
> > address hint without MAP_FIXED applied. See below my proposed way
> > around this issue because I belive that the above patch is quite
> > valuable on its own to be dropped for all archs.
>
> I don't really like your solution sorry :) The fact that you've had to
> patch seven arches seems like a red flag.
>
> I think this is a generic problem with MAP_FIXED, which I've heard
> userspace folks complain about in the past.
The thing is that we canno change MAP_FIXED behavior as it is carved in
stone
> Currently MAP_FIXED does two things:
> 1. makes addr not a hint but the required address
> 2. blasts any existing mapping
>
> You want 1) but not 2).
+ fail if there is a clashing range
> So the right solution IMHO would be to add a new mmap flag to request
> that behaviour, ie. a fixed address but iff there is nothing already
> mapped there.
>
> I don't know the mm code well enough to know if that's hard for some
> reason, but it *seems* like it should be doable.
Yes, I have mentioned that in the previous email but the amount of code
would be even larger. Basically every arch which reimplements
arch_get_unmapped_area would have to special case new MAP_FIXED flag to
do vma lookup. So this was the most simple solution I could come up
with. If there was a general interest for MAP_FIXED_SAFE then we can
introduce it later of course. I would just like the hardening merged
sooner rather than later.
--
Michal Hocko
SUSE Labs
From 1583950542108622250@xxx Mon Nov 13 11:35:50 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
Hi Michal,
Michal Hocko <[email protected]> writes:
> On Mon 13-11-17 10:20:06, Michal Hocko wrote:
>> [Cc arm and ppc maintainers]
>
> Hmm, it turned out to be a problem on other architectures as well.
> CCing more maintainers. For your reference, we are talking about
> http://lkml.kernel.org/r/[email protected]
> which has broken architectures which do apply aligning on the mmap
> address hint without MAP_FIXED applied. See below my proposed way
> around this issue because I belive that the above patch is quite
> valuable on its own to be dropped for all archs.
I don't really like your solution sorry :) The fact that you've had to
patch seven arches seems like a red flag.
I think this is a generic problem with MAP_FIXED, which I've heard
userspace folks complain about in the past.
Currently MAP_FIXED does two things:
1. makes addr not a hint but the required address
2. blasts any existing mapping
You want 1) but not 2).
So the right solution IMHO would be to add a new mmap flag to request
that behaviour, ie. a fixed address but iff there is nothing already
mapped there.
I don't know the mm code well enough to know if that's hard for some
reason, but it *seems* like it should be doable.
cheers
From 1583943438026750523@xxx Mon Nov 13 09:42:55 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Mon 13-11-17 10:20:06, Michal Hocko wrote:
> [Cc arm and ppc maintainers]
Hmm, it turned out to be a problem on other architectures as well.
CCing more maintainers. For your reference, we are talking about
http://lkml.kernel.org/r/[email protected]
which has broken architectures which do apply aligning on the mmap
address hint without MAP_FIXED applied. See below my proposed way
around this issue because I belive that the above patch is quite
valuable on its own to be dropped for all archs.
> Thanks a lot for testing!
>
> On Sun 12-11-17 11:38:02, Joel Stanley wrote:
> > On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko <[email protected]> wrote:
> > > Hi Joel,
> > >
> > > On Wed 08-11-17 15:20:50, Michal Hocko wrote:
> > > [...]
> > >> > There are a lot of messages on the way up that look like this:
> > >> >
> > >> > [ 2.527460] Uhuuh, elf segement at 000d9000 requested but the
> > >> > memory is mapped already
> > >> > [ 2.540160] Uhuuh, elf segement at 000d9000 requested but the
> > >> > memory is mapped already
> > >> > [ 2.546153] Uhuuh, elf segement at 000d9000 requested but the
> > >> > memory is mapped already
> > >> >
> > >> > And then trying to run userspace looks like this:
> > >>
> > >> Could you please run with debugging patch posted
> > >> http://lkml.kernel.org/r/[email protected]
> > >
> > > Did you have chance to test with this debugging patch, please?
> >
> > Lots of this:
> >
> > [ 1.177266] Uhuuh, elf segement at 000d9000 requested but the memory is mapped already, got 000dd000
> > [ 1.177555] Clashing vma [dd000, de000] flags:100873 name:(null)
>
> This smells like the problem I've expected that mmap with hint doesn't
> respect the hint even though there is no clashing mapping. The above
> basically says that we didn't map at 0xd9000 but it has placed it at
> 0xdd000. The nearest (clashing) vma is at 0xdd000 so this is our new
> mapping. find_vma returns the closest vma (with addr < vm_end) for the
> given address 0xd9000 so this address cannot be mapped by any other vma.
>
> Now that I am looking at arm's arch_get_unmapped_area it does perform
> aligning for shared vmas. We do not do that for MAP_FIXED. Powepc,
> reported earlier [1] seems to suffer from the similar problem.
> slice_get_unmapped_area alignes to slices, whatever that means.
>
> I can see two possible ways around that. Either we explicitly request
> non-aligned mappings via a special MAP_$FOO (e.g. MAP_FIXED_SAFE) or
> simply opt out from the MAP_FIXED protection via ifdefs. The first
> option sounds more generic to me but also more tricky to not introduce
> other user visible effects. The later is quite straightforward. What do
> you think about the following on top of the previous patch?
>
> It is rather terse and disables the MAP_FIXED protection for arm
> comletely because I couldn't find a way to make it conditional on
> CACHEID_VIPT_ALIASING. But this can be always handled later. I find the
> protection for other archtectures useful enough to have this working for
> most architectures now and handle others specially.
>
> [1] http://lkml.kernel.org/r/[email protected]
> ---
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 61a0cb15067e..018d041a30e6 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -99,6 +99,7 @@ config ARM
select PERF_USE_VMALLOC
select RTC_LIB
select SYS_SUPPORTS_APM_EMULATION
+ select ARCH_ALIGNED_MMAPS
# Above selects are sorted alphabetically; please add new ones
# according to that. Thanks.
help
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 48d91d5be4e9..eca59d27e9f1 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -72,6 +72,7 @@ config MIPS
select RTC_LIB if !MACH_LOONGSON64
select SYSCTL_EXCEPTION_TRACE
select VIRT_TO_BUS
+ select ARCH_ALIGNED_MMAPS
menu "Machine selection"
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 22f27ec8c117..8376d16e0a4a 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -40,6 +40,7 @@ config PARISC
select GENERIC_CLOCKEVENTS
select ARCH_NO_COHERENT_DMA_MMAP
select CPU_NO_EFFICIENT_FFS
+ select ARCH_ALIGNED_MMAPS
help
The PA-RISC microprocessor is designed by Hewlett-Packard and used
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 2f629e0551e9..156f69c09c7f 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -368,6 +368,7 @@ config PPC_MM_SLICES
bool
default y if PPC_STD_MMU_64
default n
+ select ARCH_ALIGNED_MMAPS
config PPC_HAVE_PMU_SUPPORT
bool
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 640a85925060..ac1d4637a728 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -49,6 +49,7 @@ config SUPERH
select HAVE_ARCH_AUDITSYSCALL
select HAVE_FUTEX_CMPXCHG if FUTEX
select HAVE_NMI
+ select ARCH_ALIGNED_MMAPS
help
The SuperH is a RISC processor targeted for use in embedded systems
and consumer electronics; it was also used in the Sega Dreamcast
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 0be3828752e5..c265dcda3d28 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -45,6 +45,7 @@ config SPARC
select CPU_NO_EFFICIENT_FFS
select LOCKDEP_SMALL if LOCKDEP
select ARCH_WANT_RELAX_ORDER
+ select ARCH_ALIGNED_MMAPS if SPARC64
config SPARC32
def_bool !64BIT
diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
index 7ad6d77b2f22..a5cf535034d1 100644
--- a/arch/xtensa/Kconfig
+++ b/arch/xtensa/Kconfig
@@ -30,6 +30,7 @@ config XTENSA
select NO_BOOTMEM
select PERF_USE_VMALLOC
select VIRT_TO_BUS
+ select ARCH_ALIGNED_MMAPS if MMU
help
Xtensa processors are 32-bit RISC machines designed by Tensilica
primarily for embedded systems. These processors are both
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index a22718de42db..d23eb89f31c0 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -345,13 +345,19 @@ static unsigned long elf_vm_mmap(struct file *filep, unsigned long addr,
unsigned long size, int prot, int type, unsigned long off)
{
unsigned long map_addr;
+ unsigned long map_type = type;
/*
* If caller requests the mapping at a specific place, make sure we fail
* rather than potentially clobber an existing mapping which can have
- * security consequences (e.g. smash over the stack area).
+ * security consequences (e.g. smash over the stack area). Be careful
+ * about architectures which do not respect the address hint due to
+ * aligning restrictions for !fixed mappings.
*/
- map_addr = vm_mmap(filep, addr, size, prot, type & ~MAP_FIXED, off);
+ if (!IS_ENABLED(ARCH_ALIGNED_MMAPS))
+ map_type &= ~MAP_FIXED;
+
+ map_addr = vm_mmap(filep, addr, size, prot, map_type, off);
if (BAD_ADDR(map_addr))
return map_addr;
--
Michal Hocko
SUSE Labs
From 1583942998887768317@xxx Mon Nov 13 09:35:56 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Mon, Nov 13, 2017 at 10:20:06AM +0100, Michal Hocko wrote:
> [Cc arm and ppc maintainers]
>
> Thanks a lot for testing!
>
> On Sun 12-11-17 11:38:02, Joel Stanley wrote:
> > On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko <[email protected]> wrote:
> > > Hi Joel,
> > >
> > > On Wed 08-11-17 15:20:50, Michal Hocko wrote:
> > > [...]
> > >> > There are a lot of messages on the way up that look like this:
> > >> >
> > >> > [ 2.527460] Uhuuh, elf segement at 000d9000 requested but the
> > >> > memory is mapped already
> > >> > [ 2.540160] Uhuuh, elf segement at 000d9000 requested but the
> > >> > memory is mapped already
> > >> > [ 2.546153] Uhuuh, elf segement at 000d9000 requested but the
> > >> > memory is mapped already
> > >> >
> > >> > And then trying to run userspace looks like this:
> > >>
> > >> Could you please run with debugging patch posted
> > >> http://lkml.kernel.org/r/[email protected]
> > >
> > > Did you have chance to test with this debugging patch, please?
> >
> > Lots of this:
> >
> > [ 1.177266] Uhuuh, elf segement at 000d9000 requested but the memory is mapped already, got 000dd000
> > [ 1.177555] Clashing vma [dd000, de000] flags:100873 name:(null)
>
> This smells like the problem I've expected that mmap with hint doesn't
> respect the hint even though there is no clashing mapping. The above
> basically says that we didn't map at 0xd9000 but it has placed it at
> 0xdd000. The nearest (clashing) vma is at 0xdd000 so this is our new
> mapping. find_vma returns the closest vma (with addr < vm_end) for the
> given address 0xd9000 so this address cannot be mapped by any other vma.
>
> Now that I am looking at arm's arch_get_unmapped_area it does perform
> aligning for shared vmas. We do not do that for MAP_FIXED. Powepc,
> reported earlier [1] seems to suffer from the similar problem.
> slice_get_unmapped_area alignes to slices, whatever that means.
>
> I can see two possible ways around that. Either we explicitly request
> non-aligned mappings via a special MAP_$FOO (e.g. MAP_FIXED_SAFE) or
> simply opt out from the MAP_FIXED protection via ifdefs. The first
> option sounds more generic to me but also more tricky to not introduce
> other user visible effects. The later is quite straightforward. What do
> you think about the following on top of the previous patch?
>
> It is rather terse and disables the MAP_FIXED protection for arm
> comletely because I couldn't find a way to make it conditional on
> CACHEID_VIPT_ALIASING. But this can be always handled later. I find the
> protection for other archtectures useful enough to have this working for
> most architectures now and handle others specially.
Can someone provide the background information for this please?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
From 1583942095406494928@xxx Mon Nov 13 09:21:35 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
[Cc arm and ppc maintainers]
Thanks a lot for testing!
On Sun 12-11-17 11:38:02, Joel Stanley wrote:
> On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko <[email protected]> wrote:
> > Hi Joel,
> >
> > On Wed 08-11-17 15:20:50, Michal Hocko wrote:
> > [...]
> >> > There are a lot of messages on the way up that look like this:
> >> >
> >> > [ 2.527460] Uhuuh, elf segement at 000d9000 requested but the
> >> > memory is mapped already
> >> > [ 2.540160] Uhuuh, elf segement at 000d9000 requested but the
> >> > memory is mapped already
> >> > [ 2.546153] Uhuuh, elf segement at 000d9000 requested but the
> >> > memory is mapped already
> >> >
> >> > And then trying to run userspace looks like this:
> >>
> >> Could you please run with debugging patch posted
> >> http://lkml.kernel.org/r/[email protected]
> >
> > Did you have chance to test with this debugging patch, please?
>
> Lots of this:
>
> [ 1.177266] Uhuuh, elf segement at 000d9000 requested but the memory is mapped already, got 000dd000
> [ 1.177555] Clashing vma [dd000, de000] flags:100873 name:(null)
This smells like the problem I've expected that mmap with hint doesn't
respect the hint even though there is no clashing mapping. The above
basically says that we didn't map at 0xd9000 but it has placed it at
0xdd000. The nearest (clashing) vma is at 0xdd000 so this is our new
mapping. find_vma returns the closest vma (with addr < vm_end) for the
given address 0xd9000 so this address cannot be mapped by any other vma.
Now that I am looking at arm's arch_get_unmapped_area it does perform
aligning for shared vmas. We do not do that for MAP_FIXED. Powepc,
reported earlier [1] seems to suffer from the similar problem.
slice_get_unmapped_area alignes to slices, whatever that means.
I can see two possible ways around that. Either we explicitly request
non-aligned mappings via a special MAP_$FOO (e.g. MAP_FIXED_SAFE) or
simply opt out from the MAP_FIXED protection via ifdefs. The first
option sounds more generic to me but also more tricky to not introduce
other user visible effects. The later is quite straightforward. What do
you think about the following on top of the previous patch?
It is rather terse and disables the MAP_FIXED protection for arm
comletely because I couldn't find a way to make it conditional on
CACHEID_VIPT_ALIASING. But this can be always handled later. I find the
protection for other archtectures useful enough to have this working for
most architectures now and handle others specially.
[1] http://lkml.kernel.org/r/[email protected]
---
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 61a0cb15067e..018d041a30e6 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -99,6 +99,7 @@ config ARM
select PERF_USE_VMALLOC
select RTC_LIB
select SYS_SUPPORTS_APM_EMULATION
+ select ARCH_ALIGNED_MMAPS
# Above selects are sorted alphabetically; please add new ones
# according to that. Thanks.
help
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 2f629e0551e9..156f69c09c7f 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -368,6 +368,7 @@ config PPC_MM_SLICES
bool
default y if PPC_STD_MMU_64
default n
+ select ARCH_ALIGNED_MMAPS
config PPC_HAVE_PMU_SUPPORT
bool
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index a22718de42db..d23eb89f31c0 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -345,13 +345,19 @@ static unsigned long elf_vm_mmap(struct file *filep, unsigned long addr,
unsigned long size, int prot, int type, unsigned long off)
{
unsigned long map_addr;
+ unsigned long map_type = type;
/*
* If caller requests the mapping at a specific place, make sure we fail
* rather than potentially clobber an existing mapping which can have
- * security consequences (e.g. smash over the stack area).
+ * security consequences (e.g. smash over the stack area). Be careful
+ * about architectures which do not respect the address hint due to
+ * aligning restrictions for !fixed mappings.
*/
- map_addr = vm_mmap(filep, addr, size, prot, type & ~MAP_FIXED, off);
+ if (!IS_ENABLED(ARCH_ALIGNED_MMAPS))
+ map_type &= ~MAP_FIXED;
+
+ map_addr = vm_mmap(filep, addr, size, prot, map_type, off);
if (BAD_ADDR(map_addr))
return map_addr;
--
Michal Hocko
SUSE Labs
From 1583820551383618353@xxx Sun Nov 12 01:09:41 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko <[email protected]> wrote:
> Hi Joel,
>
> On Wed 08-11-17 15:20:50, Michal Hocko wrote:
> [...]
>> > There are a lot of messages on the way up that look like this:
>> >
>> > [ 2.527460] Uhuuh, elf segement at 000d9000 requested but the
>> > memory is mapped already
>> > [ 2.540160] Uhuuh, elf segement at 000d9000 requested but the
>> > memory is mapped already
>> > [ 2.546153] Uhuuh, elf segement at 000d9000 requested but the
>> > memory is mapped already
>> >
>> > And then trying to run userspace looks like this:
>>
>> Could you please run with debugging patch posted
>> http://lkml.kernel.org/r/[email protected]
>
> Did you have chance to test with this debugging patch, please?
Lots of this:
[ 1.177266] Uhuuh, elf segement at 000d9000 requested but the
memory is mapped already, got 000dd000
[ 1.177555] Clashing vma [dd000, de000] flags:100873 name:(null)
Full log is attached.
If you want to reproduce yourself and have an arm compiler lying around:
$ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make aspeed_g5_defconfig
$ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make
$ qemu-system-arm -M ast2500-evb -nographic -nodefaults -serial stdio \
-kernel arch/arm/boot/zImage \
-dtb arch/arm/boot/dts/aspeed-ast2500-evb.dtb
I'm using Qemu 2.10 which current distros ship. ymmv with older releases.
Cheers,
Joel
Hi Joel,
On Wed 08-11-17 15:20:50, Michal Hocko wrote:
[...]
> > There are a lot of messages on the way up that look like this:
> >
> > [ 2.527460] Uhuuh, elf segement at 000d9000 requested but the
> > memory is mapped already
> > [ 2.540160] Uhuuh, elf segement at 000d9000 requested but the
> > memory is mapped already
> > [ 2.546153] Uhuuh, elf segement at 000d9000 requested but the
> > memory is mapped already
> >
> > And then trying to run userspace looks like this:
>
> Could you please run with debugging patch posted
> http://lkml.kernel.org/r/[email protected]
Did you have chance to test with this debugging patch, please?
--
Michal Hocko
SUSE Labs
From 1583507993703472715@xxx Wed Nov 08 14:21:43 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
Hi,
On Wed 08-11-17 08:52:24, Joel Stanley wrote:
> Hello Michal,
>
> On Tue, Nov 7, 2017 at 3:52 PM, Stephen Rothwell <[email protected]> wrote:
> > Hi all,
> >
> > Changes since 20171106:
> >
> > The powerpc tree still had its build failure for which I applied a patch.
> >
> > The crypto tree lost its build failure.
> >
> > The akpm tree still had its build failure for which I reverted a commit.
> >
> > Non-merge commits (relative to Linus' tree): 10912
> > 10165 files changed, 524042 insertions(+), 247066 deletions(-)
>
> I tried to boot this -next tree built for the ARM platform I maintain,
> and it did not make it to userspace. When I revert your patch
> "fs/binfmt_elf.c: drop MAP_FIXED usage from elf_map" the system boots
> as expected.
>
> There are a lot of messages on the way up that look like this:
>
> [ 2.527460] Uhuuh, elf segement at 000d9000 requested but the
> memory is mapped already
> [ 2.540160] Uhuuh, elf segement at 000d9000 requested but the
> memory is mapped already
> [ 2.546153] Uhuuh, elf segement at 000d9000 requested but the
> memory is mapped already
>
> And then trying to run userspace looks like this:
Could you please run with debugging patch posted
http://lkml.kernel.org/r/[email protected]
--
Michal Hocko
SUSE Labs
From 1583465392342494489@xxx Wed Nov 08 03:04:35 +0000 2017
X-GM-THRID: 1583423641769727671
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
Hello Michal,
On Tue, Nov 7, 2017 at 3:52 PM, Stephen Rothwell <[email protected]> wrote:
> Hi all,
>
> Changes since 20171106:
>
> The powerpc tree still had its build failure for which I applied a patch.
>
> The crypto tree lost its build failure.
>
> The akpm tree still had its build failure for which I reverted a commit.
>
> Non-merge commits (relative to Linus' tree): 10912
> 10165 files changed, 524042 insertions(+), 247066 deletions(-)
I tried to boot this -next tree built for the ARM platform I maintain,
and it did not make it to userspace. When I revert your patch
"fs/binfmt_elf.c: drop MAP_FIXED usage from elf_map" the system boots
as expected.
There are a lot of messages on the way up that look like this:
[ 2.527460] Uhuuh, elf segement at 000d9000 requested but the
memory is mapped already
[ 2.540160] Uhuuh, elf segement at 000d9000 requested but the
memory is mapped already
[ 2.546153] Uhuuh, elf segement at 000d9000 requested but the
memory is mapped already
And then trying to run userspace looks like this:
[ 3.116476] Uhuuh, elf segement at 000d9000 requested but the
memory is mapped already
[ 3.116988] Failed to execute /init (error -11)
[ 3.117713] Starting init: /sbin/init exists but couldn't execute
it (error -14)
[ 3.118879] Starting init: /bin/sh exists but couldn't execute it (error -14)
[ 3.119186] Kernel panic - not syncing: No working init found. Try
passing init= option to kernel. See Linux
Documentation/admin-guide/init.rst for guidance.
[ 3.119683] CPU: 0 PID: 1 Comm: init Not tainted
4.14.0-rc8-next-20171107-00016-g9f804d9fa870 #55
[ 3.119933] Hardware name: Generic DT based system
[ 3.120205] [<8000fa9c>] (unwind_backtrace) from [<8000d2dc>]
(show_stack+0x10/0x14)
[ 3.120462] [<8000d2dc>] (show_stack) from [<800174bc>] (panic+0xb8/0x244)
[ 3.120688] [<800174bc>] (panic) from [<80355298>] (kernel_init+0xc8/0xf0)
[ 3.120880] [<80355298>] (kernel_init) from [<8000a5e0>]
(ret_from_fork+0x14/0x34)
I've built the aspeed_g5_defconfig, which is a 32 bit ARM machine. The
full dmesg is attached.
I noted a report of this for ppc64, but I'm not on that list:
https://marc.info/?l=linuxppc-embedded&m=151005537413751&w=2
Cheers,
Joel