* Helge Deller <deller@xxxxxxxxxx> [240911 15:20]: > This is a RFC to change the behaviour of mmap(MAP_STACK) to be > sufficient to map memory for usage as stack on all architectures. > Currently MAP_STACK is a no-op on Linux, and instead MAP_GROWSDOWN > has to be used. > To clarify, here is the relevant info from the mmap() man page: > > MAP_GROWSDOWN > This flag is used for stacks. It indicates to the kernel virtual > memory system that the mapping should extend downward in memory. The > return address is one page lower than the memory area that is > actually created in the process's virtual address space. Touching an > address in the "guard" page below the mapping will cause the mapping > to grow by a page. This growth can be repeated until the mapping > grows to within a page of the high end of the next lower mapping, > at which point touching the "guard" page will result in a SIGSEGV > signal. > > MAP_STACK (since Linux 2.6.27) > Allocate the mapping at an address suitable for a process or thread > stack. > > This flag is currently a no-op on Linux. However, by employing this > flag, applications can ensure that they transparently obtain support > if the flag is implemented in the future. Thus, it is used in the > glibc threading implementation to allow for the fact that > some architectures may (later) require special treatment for > stack allocations. A further reason to employ this flag is > portability: MAP_STACK exists (and has an effect) on some > other systems (e.g., some of the BSDs). > > The reason to suggest this change is, that on the parisc architecture the > stack grows upwards. As such, using solely the MAP_GROWSDOWN flag will not > work. Note that there exists no MAP_GROWSUP flag. > By changing the behaviour of MAP_STACK to mark the memory area with the > VM_STACK bit (which is VM_GROWSUP or VM_GROWSDOWN depending on the > architecture) the MAP_STACK flag does exactly what people would expect on > all platforms. > > This change should have no negative side-effect, as all code which > used mmap(MAP_GROWSDOWN | MAP_STACK) still work as before. > > Signed-off-by: Helge Deller <deller@xxxxxx> > > diff --git a/include/linux/mman.h b/include/linux/mman.h > index bcb201ab7a41..66bc72a0cb19 100644 > --- a/include/linux/mman.h > +++ b/include/linux/mman.h > @@ -156,6 +156,7 @@ calc_vm_flag_bits(unsigned long flags) > return _calc_vm_trans(flags, MAP_GROWSDOWN, VM_GROWSDOWN ) | > _calc_vm_trans(flags, MAP_LOCKED, VM_LOCKED ) | > _calc_vm_trans(flags, MAP_SYNC, VM_SYNC ) | > + _calc_vm_trans(flags, MAP_STACK, VM_STACK ) | Right now MAP_STACK can be used to set VM_NOHUGEPAGE, but this will change the user interface to create a vma that will grow. I'm not entirely sure this is okay? That is mmap(MAP_STACK) would set VM_NOHUGEPAGE right now, with this change you'd get VM_NOHUGEPAGE | VM_GROWS<something> > _calc_vm_trans(flags, MAP_STACK, VM_NOHUGEPAGE) | > arch_calc_vm_flag_bits(flags); > } >
