Re: [PATCH 0/3] mm: __access_remote_vm with per-VMA lock

[Lorenzo Stoakes <ljs@kernel.org>]

On Thu, Jun 18, 2026 at 10:37:03PM +0200, David Hildenbrand (Arm) wrote:
> On 6/17/26 15:33, Suren Baghdasaryan wrote:
> > On Wed, Jun 17, 2026 at 2:42 AM David Hildenbrand (Arm)
> > <david@kernel.org> wrote:
> >>
> >> On 6/17/26 03:10, Suren Baghdasaryan wrote:
> >>>
> >>> Thanks for the patchset Rik!
> >>> Previously when I looked into using per-VMA locks in
> >>> access_remote_vm(), the biggest hurdle was get_user_pages_remote(),
> >>> which required mmap_lock. Your implementation avoids altogether and
> >>> keeps the code much simpler than what I expected.
> >>
> >> But, wouldn't we, in general, also want to teach GUP to just work with per-VMA
> >> locks?
> >
> > Matthew suggested using gup_fast in access_remote_vm before, and I
> > looked into that. The biggest issue there is that gup_fast assumes it
> > always operates on current->mm, not on the remote one. Reworking that
> > is quite an undertaking.
>
> Right, that's more tricky, IIRC the CPU from a remote MM might not get an IPI
> sent to sync. (but my memory is fuzzy on that)
>
> > Teaching GUP in general to work with per-VMA locks I think would also
> > be much harder than what this patchset does and would require a GUP
> > expert (which I am unfortunately not).
>
> Well, "harder" is not really an excuse ;)

Agreed.

We shouldn't just tack on new features like this without improving what already
exists.

Really a series that adds a new feature should have patches that first clean
things up to lay the foundations.

I think we've been a bit too permissive of 'just add more code' series in mm in
general when we know the ground around it is already shakey.

We all need to do our part in improving the codebase.

>
> Where a folio_walk really shines at is that you can just walk a PMD entry and
> process it all at once, instead of returning 512. Where it doesn't shine is that
> you have to walk the complete page table again for each individual PTE.
>
> ... which is also what we do right now through get_user_page_vma_remote(), which
> is rather suboptimal.
>
> Ideally, you'd obtain multiple page ranges (with upper limit on the ranges) in
> one shot, whereby each page range belongs to the same compound page, and there
> is exactly one page/folio ref on a range. [we discussed that in other context
> recently]
>
> Then, you can just let GUP do the GUP work, without re-implementing it for some
> special cases elsewhere. And others can benefit from the work.
>
>
> So I'd really like us to find out what it would take to teach ordinary GUP (or
> better, some new GUP interface) to run under the VMA lock. We can start with the
> existing interface to GUP a single page to KIS.
>
> Maybe having a new GUP interface that consumes a VMA instead of an MM could be
> the first start to enable per-VMA locks?
>
> All GUP does is walk page tables and call fault handlers. userfaultfd is nasty,
> but existing page faults must also deal with that having to fallback to the MM
> lock, so it sounds like a solvable problem with some churn?

Well I think a critical problem here, as pointed out by Suren, is that holding a
VMA lock means that the VMAs around you can change and in ways that are quite
problematic.

E.g. The moment you drop the VMA lock that VMA might get freed and then merged
with something else, and the next VMA you consume is the same one you just
partially walked, for instance.

Now perhaps you could reason your way around this, but I'm pretty sure there are
cases where you might actually miss VMAs due to races (Suren knows best).

And also without an mmap lock people can unmap and map new VMAs in the range as
you go through which might cause weirdness as well.

Really, unless you are dealing with a single VMA in the range, I suspect GUP
needs to stabilise that whole range.

If we could find a way to have GUP fast-path the single VMA case sensibly, then
that's probably workable?

And I agree special-casing only one place but not others sucks.

Perhaps we could find a way to get this improvement without it being quite so
'tacked on' but without needing significant rework of GUP, but in either case I
broadly agree we need to improve the codebase as part of the changes.

>
> --
> Cheers,
>
> David

Thanks, Lorenzo