On 9/17/26 18:22, Lorenzo Stoakes (ARM) wrote: > We currently disallow the installation of lightweight guard regions in VMAs > whose flags intersect VMA_SPECIAL_FLAGS or VMA_HUGETLB_BIT, or > VMA_LOCKED_BIT unless allow_locked is set. > > hugetlb VMAs set VMA_DONTEXPAND_BIT so this was already redundant, > VMA_SPECIAL_FLAGS already sufficed. > > However, now that VMA_IO_BIT is only set if VMA_PFNMAP or VMA_MIXEDMAP_BIT > is set, this check collapses to being the equivalent of > !vma_can_merge(). > > Update is_valid_guard_vma() to reflect this. > > No functional change intended. > > Signed-off-by: Lorenzo Stoakes (ARM) <[email protected]> > --- > mm/madvise.c | 20 +++++++++++++------- > 1 file changed, 13 insertions(+), 7 deletions(-) > > diff --git a/mm/madvise.c b/mm/madvise.c > index 467601a8525b..0922d5f07a12 100644 > --- a/mm/madvise.c > +++ b/mm/madvise.c > @@ -1221,19 +1221,25 @@ static long madvise_remove(struct madvise_behavior > *madv_behavior) > return error; > } > > -static bool is_valid_guard_vma(struct vm_area_struct *vma, bool allow_locked) > +static bool is_valid_guard_vma(const struct vm_area_struct *vma, > + bool allow_locked) > { > - vm_flags_t disallowed = VM_SPECIAL | VM_HUGETLB; > - > /* > - * A user could lock after setting a guard range but that's fine, as > + * A user could lock after setting a guard range but that's fine as > * they'd not be able to fault in. The issue arises when we try to zap > * existing locked VMAs. We don't want to do that. > */ > - if (!allow_locked) > - disallowed |= VM_LOCKED; > + if (!allow_locked && vma_test(vma, VMA_LOCKED_BIT)) > + return false; > + /* > + * Guard regions require a VMA whose page tables are managed solely by > + * the core, which is also what merging requires, so disallow any flags > + * that would prevent a merge. > + */ > + if (!vma_can_merge(vma)) > + return false;
Acked-by: David Hildenbrand (Arm) <[email protected]> -- Cheers, David
