Re: [PATCH v5 21/38] uprobes: remove VM_IO, set VM_MIXEDMAP for mapped kernel pages
From: Lorenzo Stoakes (ARM)
Date: Mon Oct 12 2026 - 14:30:28 EST
On Mon, Oct 12, 2026 at 08:16:56PM +0200, David Hildenbrand (Arm) wrote:
> On 10/9/26 20:04, Lorenzo Stoakes (ARM) wrote:
> > These are not MMIO pages so VMA_IO_BIT is an inappropriate flag to set.
> >
> > Instead, set them VMA_MIXEDMAP_BIT as they are kernel mappings and this is
> > the appropriate flag to set for those.
> >
> > This provides the semantics required - no VMA merging is permitted, but
> > does not prevent GUP.
> >
> > However this has no meaningful impact as these are refcounted and thus can
> > be GUPed.
> >
> > A previous commit already prevented __mm_populate() from being invoked on
> > XOL areas, which VMA_IO_BIT was previously relied upon to do, so that is no
> > longer required.
> >
> > Both VMAs set a VMA name, so always_dump_vma() returns true before
> > vma_dump_size() reaches its VMA_IO_BIT check, and thus there is no change
> > in core dump behaviour.
> >
> > Change this for both the core xol_add_vma() function and the x86-specific
> > get_uprobe_trampoline() function.
> >
> > Reviewed-by: Suren Baghdasaryan <surenb@xxxxxxxxxx>
> > Signed-off-by: Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx>
> > ---
> > arch/x86/kernel/uprobes.c | 2 +-
> > kernel/events/uprobes.c | 4 ++--
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
> > index 65a2de82ecd2..0f60c0d076b6 100644
> > --- a/arch/x86/kernel/uprobes.c
> > +++ b/arch/x86/kernel/uprobes.c
> > @@ -715,7 +715,7 @@ static struct vm_area_struct *get_uprobe_trampoline(struct mm_struct *mm, unsign
> >
> > *new_mapping = true;
> > return _install_special_mapping(mm, vaddr, PAGE_SIZE,
> > - VM_READ|VM_EXEC|VM_MAYEXEC|VM_MAYREAD|VM_IO,
> > + VM_READ|VM_EXEC|VM_MAYEXEC|VM_MAYREAD|VM_MIXEDMAP,
> > &tramp_mapping);
>
> So these can now be GUP'ed. Let's hope that's fine ;)
Yeah the commit message mentions that. Since they're refcounted I don't think
there's any problem.
>
> Acked-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>
Thanks!
>
> --
> Cheers,
>
> David
--
Cheers, Lorenzo