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) <[email protected]> > --- > 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. > + * 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 <[email protected]> -- Best Regards, Yan, Zi
