Re: [PATCH] ARC: update the help message for CONFIG_ARC_BUILTIN_DTB_NAME

2024-09-02 Thread Vineet Gupta
On 8/31/24 23:50, Masahiro Yamada wrote: > On Sun, Sep 1, 2024 at 8:02 AM Vineet Gupta wrote: >> >> >> On 8/31/24 03:13, Masahiro Yamada wrote: >>> On Sat, Aug 31, 2024 at 7:10 PM Masahiro Yamada >>> wrote: Commit abe11ddea1d7 ("ARC: [plat-arcfpga]: Enabling DeviceTree for Angel4 boa

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

2024-09-02 Thread Mark Brown
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 3/3] mm: Care about shadow stack guard gap when getting an unmapped area

2024-09-02 Thread Mark Brown
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 2/3] mm: Pass vm_flags to generic_get_unmapped_area()

2024-09-02 Thread Mark Brown
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. Sig

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

2024-09-02 Thread Mark Brown
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