On Thu, Feb 4, 2021 at 9:59 PM Jason Gunthorpe jgg@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@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