[PATCH] RFC: dma-buf: Require VM_SPECIAL vma for mmap

[Daniel Vetter]

On Thu, Feb 4, 2021 at 9:59 PM Jason Gunthorpe <jgg at ziepe.ca> wrote:
>
> On Thu, Feb 04, 2021 at 09:19:57PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 4, 2021 at 9:09 PM Jason Gunthorpe <jgg at ziepe.ca> wrote:
> > >
> > > On Thu, Feb 04, 2021 at 08:59:59PM +0100, Daniel Vetter wrote:
> > >
> > > > So I think just checking for VM_PFNMAP after the vma is set up should
> > > > be enough to guarantee we'll only have pte_special ptes in there,
> > > > ever. But I'm not sure, this stuff all isn't really documented much
> > > > and the code is sometimes a maze (to me at least).
> > >
> > > Yes, that makes sense. VM_PFNMAP and !VM_MIXEDMAP seems like the right
> > > check after the VMA is populated
> > >
> > > But how do you stuff special pfns into a VMA outside the fault
> > > handler?
> >
> > Many drivers we have don't have dynamic buffer management (kinda
> > overkill for a few framebuffers on a display-only IP block), so the
> > just remap_pfn_range on ->mmap, and don't have a fault handler at all.
>
> remap_pfn_range() makes sense, do you expect drivers using struct page
> backed memory to call that as well?

All the ones using CMA through dma_alloc_coherent end up in there with
the dma_mmap_wc function. So yeah we have tons already.

The drivers with dynamic memory management all use vm_insert_pfn, even
when the buffer is in system memory and struct page backed. I think
those are the two cases. There's another mmap in drm/i915, but that
should never leave intel-specific userspace, and I think we're also
phasing it out somewhat. Either way, should never show up in a shared
buffer usecase, ever, so I think we can ignore it.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch