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 <[email protected]>
> > Signed-off-by: Lorenzo Stoakes (ARM) <[email protected]>
> > ---
> >  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) <[email protected]>

Thanks!

>
> --
> Cheers,
>
> David

--
Cheers, Lorenzo

Reply via email to