[PATCH v2 0/3] mm: Care about shadow stack guard gap when getting an unmapped area

As covered in the commit log for c44357c2e76b ("x86/mm: care about shadow stack guard gap during placement") our current mmap() implementation does not take care to ensure that a new mapping isn't placed with existing mappings inside it's own guard gaps. This is particularly important for shadow st

[PATCH v2 1/3] mm: Make arch_get_unmapped_area() take vm_flags by default

When we introduced arch_get_unmapped_area_vmflags() in 961148704acd ("mm: introduce arch_get_unmapped_area_vmflags()") we did so as part of properly supporting guard pages for shadow stacks on x86_64, which uses a custom arch_get_unmapped_area(). Equivalent features are also present on both arm64 a

[PATCH v2 2/3] mm: Pass vm_flags to generic_get_unmapped_area()

In preparation for using vm_flags to ensure guard pages for shadow stacks supply them as an argument to generic_get_unmapped_area(). The only user outside of the core code is the PowerPC book3s64 implementation which is trivially wrapping the generic implementation in the radix_enabled() case. No

[PATCH v2 3/3] mm: Care about shadow stack guard gap when getting an unmapped area

As covered in the commit log for c44357c2e76b ("x86/mm: care about shadow stack guard gap during placement") our current mmap() implementation does not take care to ensure that a new mapping isn't placed with existing mappings inside it's own guard gaps. This is particularly important for shadow st

Re: [PATCH 3/3] mm: Care about shadow stack guard gap when getting an unmapped area

On Mon, Sep 02, 2024 at 08:08:15PM +0100, Mark Brown wrote: As covered in the commit log for c44357c2e76b ("x86/mm: care about shadow stack guard gap during placement") our current mmap() implementation does not take care to ensure that a new mapping isn't placed with existing mappings inside it'

Re: [PATCH 2/3] mm: Pass vm_flags to generic_get_unmapped_area()

On Mon, Sep 02, 2024 at 08:08:14PM +0100, Mark Brown wrote: In preparation for using vm_flags to ensure guard pages for shadow stacks supply them as an argument to generic_get_unmapped_area(). The only user outside of the core code is the PowerPC book3s64 implementation which is trivially wrappin

Re: [PATCH 3/3] mm: Care about shadow stack guard gap when getting an unmapped area

On Tue, Sep 03, 2024 at 08:57:20PM +0100, Mark Brown wrote: On Tue, Sep 03, 2024 at 03:41:49PM -0400, Liam R. Howlett wrote: * Mark Brown [240902 15:09]: > +static inline unsigned long stack_guard_placement(vm_flags_t vm_flags) > +{ > + if (vm_flags & VM_SHADOW_STACK) > + return PA

[PATCH 03/15] kbuild: move non-boot builtin DTBs to .init.rodata section

Some architectures support embedding boot DTB(s) in vmlinux. These architectures, except MIPS and MicroBlaze, expect a single DTB in the .dtb.init.rodata section. MIPS embeds multiple DTBs in vmlinux. MicroBlaze embeds a DTB in its own __fdt_blob section instead of the .dtb.init.rodata section. Fo

[PATCH 02/15] kbuild: split device tree build rules into scripts/Makefile.dtbs

scripts/Makefile.lib is included not only from scripts/Makefile.build but also from scripts/Makefile.{modfinal,package,vmlinux,vmlinux_o}, where DT build rules are not required. Split the DT build rules out to scripts/Makefile.dtbs, and include it only when necessary. Signed-off-by: Masahiro Yama

[PATCH 00/15] kbuild: refactor DTB build rules, introduce a generic built-in boot DTB support

01 and 02 are kbuild cleanups. 03 and 04 parepare to wrap boot DTBs in scripts/Makefile.vmlinux. My plan is to 05-13 to each arch ML in the next cycle, but they are included in this patch set so that reviewers can understand what will happen in the future. Masahiro Yamada (15): kbuild: add

[PATCH 01/15] kbuild: add intermediate targets for Flex/Bison in scripts/Makefile.host

Flex and Bison are used only for host programs. Move their intermediate target processing from scripts/Makefile.build to scripts/Makefile.host. Signed-off-by: Masahiro Yamada --- scripts/Makefile.build | 35 --- scripts/Makefile.host | 5 + 2 files changed,

[PATCH 04/15] kbuild: add generic support for built-in boot DTBs

Some architectures embed boot DTBs in vmlinux. A potential issue for these architectures is a race condition during parallel builds because Kbuild descends into arch/*/boot/dts/ twice. One build thread is initiated by the 'dtbs' target, which is a prerequisite of the 'all' target in the top-level

[PATCH 05/15] MIPS: migrate to generic rule for built-in DTBs

Select GENERIC_BUILTIN_DTB and BUILTIN_DTB_ALL when built-in DTB support is enabled. DTBs compiled under arch/mips/boot/dts/ will be wrapped and compiled in scripts/Makefile.vmlinux. Signed-off-by: Masahiro Yamada --- arch/mips/Kconfig | 2 ++ arch/mips/Makefile

[PATCH 07/15] LoongArch: migrate to the generic rule for built-in DTB

Select GENERIC_BUILTIN_DTB when built-in DTB support is enabled. Signed-off-by: Masahiro Yamada --- arch/loongarch/Kbuild| 1 - arch/loongarch/Kconfig | 1 + arch/loongarch/boot/dts/Makefile | 2 -- 3 files changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/loongar

[PATCH 06/15] riscv: migrate to the generic rule for built-in DTB

Select GENERIC_BUILTIN_DTB when built-in DTB support is enabled. To keep consistency across architectures, this commit also renames CONFIG_BUILTIN_DTB_SOURCE to CONFIG_BUILTIN_DTB_NAME. Signed-off-by: Masahiro Yamada --- arch/riscv/Kbuild | 1 - arch/riscv/Kconfig

[PATCH 09/15] openrisc: migrate to the generic rule for built-in DTB

Select GENERIC_BUILTIN_DTB to use the generic rule to support built-in DTB. To keep consistency across architectures, this commit also renames CONFIG_OPENRISC_BUILTIN_DTB_NAME to CONFIG_BUILTIN_DTB_NAME. Signed-off-by: Masahiro Yamada --- arch/openrisc/Kbuild | 1 - arch/

[PATCH 08/15] ARC: migrate to the generic rule for built-in DTB

Select GENERIC_BUILTIN_DTB to use the generic rule to support built-in DTB. To keep consistency across architectures, this commit also renames CONFIG_ARC_BUILTIN_DTB_NAME to CONFIG_BUILTIN_DTB_NAME. Signed-off-by: Masahiro Yamada --- arch/arc/Kconfig | 7 --- arch

[PATCH 10/15] xtensa: migrate to the generic rule for built-in DTB

Select GENERIC_BUILTIN_DTB to use the generic rule to support built-in DTB. To keep consistency across architectures, this commit also renames CONFIG_BUILTIN_DTB_SOURCE to CONFIG_BUILTIN_DTB_NAME. Signed-off-by: Masahiro Yamada --- arch/xtensa/Kbuild | 2 +- arch/xtens

[PATCH 12/15] sh: migrate to the generic rule for built-in DTB

Select GENERIC_BUILTIN_DTB when built-in DTB support is enabled. To keep consistency across architectures, this commit also renames CONFIG_USE_BUILTIN_DTB to CONFIG_BUILTIN_DTB, and CONFIG_BUILTIN_DTB_SOURCE to CONFIG_BUILTIN_DTB_NAME. Signed-off-by: Masahiro Yamada --- arch/sh/Kbuild

[PATCH 11/15] nios2: migrate to the generic rule for built-in DTB

Select GENERIC_BUILTIN_DTB when built-in DTB support is enabled. To keep consistency across architectures, this commit also renames CONFIG_NIOS2_DTB_SOURCE_BOOL to CONFIG_BUILTIN_DTB, and CONFIG_NIOS2_DTB_SOURCE to CONFIG_BUILTIN_DTB_NAME. Signed-off-by: Masahiro Yamada --- arch/nios2/Kbuild

[PATCH 13/15] microblaze: migrate to the generic rule for built-in DTB

Select GENERIC_BUILTIN_DTB to use the generic rule to support built-in DTB. MicroBlaze is the only architecture that embeds the boot DTB into its own section, __fdt_blob, and hard-codes the section size to 64kB. All other architectures that support embedded DTBs use the .dtb.init.rodata handled b

[PATCH 14/15] kbuild: rename CONFIG_GENERIC_BUILTIN_DTB to CONFIG_BUILTIN_DTB

Now that all architectures have migrated to the generic built-in DTB support, the GENERIC_ prefix is no longer necessary. Signed-off-by: Masahiro Yamada --- Makefile | 2 +- arch/arc/Kconfig | 2 +- arch/loongarch/Kconfig | 1 - arch

[PATCH 15/15] kbuild: use .init.rodata section unconditionally for cmd_wrap_S_dtb

Boot DTBs are now wrapped and compiled in scripts/Makefile.vmlinux. The cmd_wrap_S_dtb rule in scripts/Makefile.dtbs is now only used for generic purposes, so the .init.rodata section should be used unconditionally. Signed-off-by: Masahiro Yamada --- scripts/Makefile.dtbs | 4 +--- 1 file chan

Re: [PATCH RFC v2 0/4] mm: Introduce MAP_BELOW_HINT

On Thu, Aug 29, 2024 at 12:15:57AM -0700, Charlie Jenkins wrote: > Some applications rely on placing data in free bits addresses allocated > by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the > address returned by mmap to be less than the 48-bit address space, > unless the hint a