On Sat, Oct 3, 2026 at 6:40 PM Lorenzo Stoakes (ARM) <[email protected]> wrote: > > When populating a VMA range via the aptly named populate_vma_page_range() > an unreadable VMA will always eventually fail with -EFAULT. > > That a VMA is accessible is always checked, however VMA_MAYREAD_BIT is not. > > All user mappings always have VMA_MAYREAD_BIT set, so this check only > impacts kernel mappings. > > It is implemented specifically to disallow population of uprobes XOL > mappings which are exec-only. > > A nasty interaction with these mappings may occur if they are mlocked, so > actively disallow this early. > > This allows a subsequent commit to remove the VM_IO check in > __mm_populate() which otherwise requires non-MMIO mappings to be wrongly > flagged simply as a workaround. > > Acked-by: Zi Yan <[email protected]> > Signed-off-by: Lorenzo Stoakes (ARM) <[email protected]>
Reviewed-by: Suren Baghdasaryan <[email protected]> > --- > mm/gup.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/mm/gup.c b/mm/gup.c > index c2dfcb4744bc..e6310a7cc05b 100644 > --- a/mm/gup.c > +++ b/mm/gup.c > @@ -1836,6 +1836,10 @@ long populate_vma_page_range(struct vm_area_struct > *vma, > if (!vma_is_accessible(vma)) > return -EFAULT; > > + /* Unreadable VMAs also cannot be faulted in. */ > + if (!vma_test(vma, VMA_MAYREAD_BIT)) > + return -EFAULT; > + > gup_flags = FOLL_TOUCH; > /* > * We want to touch writable mappings with a write fault in order > > -- > 2.55.0 >
