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

[Jane Chu]

On 4/19/2023 4:21 PM, Jane Chu wrote:
> 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?

Sorry, not 'oblivious'. how about a malicious user process get an fd via 
memfd_create() and attempt to truncate more than it mmap'ed?

> If the vma merge is otherwise harmless, does it bring benefit other than 
> being one vma less?
>
> thanks!
> -jane