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) <[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.
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 <[email protected]> Thanks! > > > -- > Best Regards, > Yan, Zi > -- Cheers, Lorenzo
