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