On Wed, Nov 4, 2020 at 3:00 PM Jason Gunthorpe <jgg@xxxxxxxx> wrote: > > On Sun, Nov 01, 2020 at 11:50:39PM +0100, Daniel Vetter wrote: > > > It's not device drivers, but everyone else. At least my understanding > > is that VM_IO | VM_PFNMAP means "even if it happens to be backed by a > > struct page, do not treat it like normal memory". And gup/pup_fast > > happily break that. I tried to chase the history of that test, didn't > > turn up anything I understood much: > > VM_IO isn't suppose do thave struct pages, so how can gup_fast return > them? > > I thought some magic in the PTE flags excluded this? I don't really have a box here, but dma_mmap_attrs() and friends to mmap dma_alloc_coherent memory is set up as VM_IO | VM_PFNMAP (it's actually enforced since underneath it uses remap_pfn_range), and usually (except if it's pre-cma carveout) that's just normal struct page backed memory. Sometimes from a cma region (so will be caught by the cma page check), but if you have an iommu to make it device-contiguous, that's not needed. I think only some architectures have a special io pte flag, and those are only used for real mmio access. And I think the popular ones all don't. But that stuff is really not my expertise, just some drive-by reading I've done to understand how the pci mmap stuff works (which is special in yet other ways I think). So probably I'm missing something, but I'm not seeing anything that prevents this from coming out of a pup/gup_fast. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
