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

[Lorenzo Stoakes <ljs@kernel.org>]

On Fri, Jun 26, 2026 at 10:33:19PM +0200, David Hildenbrand (Arm) wrote:
> On 6/25/26 13:22, Rik van Riel wrote:
> > On Thu, 2026-06-25 at 08:32 +0200, David Hildenbrand (Arm) wrote:
> >> On 6/25/26 03:50, Rik van Riel wrote:
> >>>
> >>> v2:
> >>>  - simplify the code, which should be ok because these copies are <
> >>> PAGE_SIZE
> >>>  - clean up the code
> >>>  - fix locking wrt tlb_remove_table_sync_one()
> >>>  - hopefully address all the other comments
> >>
> >> You mean, ignoring my comments about not reiplementing GUP entirely?
> >>
> >> NAK
> >
> > Do we actually have a path to doing that?
>
> Well, I know what we do not want to reimplement GUP in some GUP users unless
> really unavoidable. And I want that explored first before moving further into
> this growing complexity in a GUP users.
>
> >
> > I misread that as more of a wish list thing, not
> > as something we could realistically do today.
>
> I really don't know how you concluded that.
>
> I mean, I know, my English is bad, but it's hard for me to get how
>
> 	"Yeah, we're not doing that unless inevitable."
>
> is a wish list.
>
> Yeah, well, ok, my kids treat also a "no" as a wish list ;)
>
> >
> > How would I go about making that mmap_lock-less
> > GUP a reality?
> >
> > What are the prerequisites?
>
> Did you actually read at least some of the stuff I wrote in my mails? You know,
> the ones where you didn't reply to? :)
>
> Seeing a v2 with some weird gup-fast-like looking reimplementatiom (eww) is not
> something I enjoyed at this point. We don't need another set of special page
> table walkers.
>
> We really need someone to look into this with some GUP experience or the
> willingness to properly think the GUP lookup+fault path through, instead of
> adding some creative workarounds to selective GUP user.
>
> I will try to find some time to think it through, but my time would be better
> spent guiding someone (and definitely not someones LLM) to understand
>
> (1) which interface we could start with (as I said, a GUP interface where we
> pass a VMA-lcoked / mm-read-lcoked VMA instead of the MM)
>
> (2) which faults we could automatically resolve under VMA lock (I mentioned
> userfaultfd is tricky but the existing GUP call already doesn't trigger uffd)
>
> (3) whether gup-fast could be reused to some degree, or what it would take in
> order to do that.
>
> --
> Cheers,
>
> David

I agree with everything David said here.

In general Rik do make sure to engage with reviewers during the review and reply
to points raised so we can have a healthy discussion (I see you replied to me
thanks for that! So hopefully this is now resolved).

It'll save you going off and doing X, Y + Z in contradiction of comments you
perhaps missed or felt were nice-to-haves, only to find that they
were in fact critical blockers that prevent your series from being merged.

With review workload as it is this not only saves you time, stress + energy, but
saves your reviewers from the same :)

Generally if there's feedback, response to all of it is expected and really
required, albeit obviously for reasons of economy an aggregrate response or
implied acks on nits are fine.

Thanks, Lorenzo