Re: + fix-zero-copy-i-o-on-__get_user_pages-allocated-pages.patch added to mm-hotfixes-unstable branch

[Jason Gunthorpe <jgg@ziepe.ca>]

On Fri, May 09, 2025 at 10:11:01AM -0700, John Hubbard wrote:
> On 5/9/25 9:30 AM, Pantelis Antoniou wrote:
> > On Thu, 8 May 2025 21:34:28 +0200
> > David Hildenbrand <david@redhat.com> wrote:
> ...
> > So what's the plan now?
> > 
> > DRM seems to be the first place to be fixed, however am I wrong in
> > thinking that most of the uses of remap_pfn_range() are wrong in the
> > context of system page backed memory?
> > 
> > Should we start with an implementation of something like remap_range()
> > which does not set PFNMAP bit. Its use is wrong in that context IMO.
> > 
> > And then move to DRM proper and replace the call to remap_pfn_range()
> > with it and see how far we go.
> > 
> That sounds like the right approach to me. Because the way we get into
> these problems is mostly due to the lack of a clear example, and so
> providing something correct to call is the way out.

Thing is if you want to just install struct page memory you don't need
MIXEDMAP or a special call, just insert the pages in the normal way.

The issue here seems to be that the DRM caller wants to mix and match
struct page and non-struct page memory, so I think you want an
entirely different API for managing effectively a scatter of two
different memory types and computing what the proper VMA flags should
be based on what was given.

OR DRM is actually using remap_pfn specifical because it does not want
3rd parties taking the page refcount because that destroys its
lifetime model..

Jason