Re: [PATCH] mm/mmap: Map MAP_STACK to VM_STACK

[Jane Chu]

On 4/18/2023 2:18 PM, Andrew Morton wrote:
> On Tue, 18 Apr 2023 17:02:30 -0400 Waiman Long <longman@xxxxxxxxxx> wrote:
[..]
> > ...
> >
> > --- a/include/linux/mman.h
> > +++ b/include/linux/mman.h
> > @@ -152,6 +152,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     ) |
> >   	       arch_calc_vm_flag_bits(flags);
> >   }
>
> The mmap(2) manpage says
>
>    This flag is currently a no-op on Linux.  However, by employing
>    this flag, applications can ensure that they transparently ob- tain
>    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 treat- ment 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).
>
> so please propose an update for this?

Just curious, why isn't MAP_STACK implemented in Linux kernel? what does 
it take to implement it?

Also, could there be other potential issue with the vma merge, such as, 
the user process start to truncate half of the anonymous memory vma 
range oblivious to the fact that the vma has 'grown' into its stack and 
it might be attempting to unmap some of its stack range?

If the vma merge is otherwise harmless, does it bring benefit other than 
being one vma less?

thanks!
-jane