[PATCH v3 05/40] mm/vma: ensure mmap_prepare doesn't set actions on a mergeable vma

[Lorenzo Stoakes (ARM)]

On Thu, Sep 24, 2026 at 03:28:10PM -0400, Zi Yan wrote:
> On Thu Sep 17, 2026 at 12:22 PM EDT, Lorenzo Stoakes (ARM) wrote:
> > When a user requests an mmap_action be performed in mmap_prepare, this
> > involves populating the VMA range with data.
> >
> > However, if the VMA is mergeable, it might then mistakenly be merged with
> > another VMA without having populated the range.
> >
> > Every mmap action currently available sets VMA flags such that the VMA
> > cannot be merged.
> >
> > However, to ensure that no future mmap action falls foul of this, assert
> > that this is the case upon mmap_prepare validation.
> >
> > Signed-off-by: Lorenzo Stoakes (ARM) <ljs at kernel.org>
> > ---
> >  mm/vma.c | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/mm/vma.c b/mm/vma.c
> > index d6ed10cefc8f..62f2ce1ad5a1 100644
> > --- a/mm/vma.c
> > +++ b/mm/vma.c
> > @@ -2809,6 +2809,15 @@ static int mmap_validate(unsigned long prev_start, unsigned long prev_end,
> >  int mmap_prepare_validate(const struct vm_area_desc *prev_desc,
> >  			  const struct vm_area_desc *desc)
> >  {
> > +	/*
> > +	 * It is not valid to execute mmap actions for VMAs which can be merged,
>
> Is it better to say "for VMAs ... after mmap_action_prepare()"? When I
> first read this, I wonder why the check is done after
> mmap_action_prepare(), which does some work based on action.type. Then,
> I realize mmap_action_prepare() changes desc->vma_flags and affect its
> mergeablitiy.

Ack, good point will update!

>
> > +	 * as any such merge would leave portions of the mapping incorrectly
> > +	 * unmapped.
> > +	 */
> > +	if (vma_flags_can_merge(&desc->vma_flags) &&
> > +	    WARN_ON_ONCE(desc->action.type != MMAP_NOTHING))
> > +		return -EINVAL;
> > +
> >  	return mmap_validate(prev_desc->start, prev_desc->end,
> >  			     desc->start, desc->end,
> >  			     &prev_desc->vma_flags, &desc->vma_flags);
>
>
> Otherwise, LGTM.
>
> Reviewed-by: Zi Yan <ziy at nvidia.com>

Thanks!

>
>
> --
> Best Regards,
> Yan, Zi
>

--
Cheers, Lorenzo