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