On Wed, Nov 4, 2020 at 5:21 PM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Wed, Nov 04, 2020 at 04:54:19PM +0100, Daniel Vetter wrote: > > 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. > > dma_mmap_* memory may or may not be page backed, but it absolutely > must not be resolved by get_user_pages and friends as it is special. > So yes, not being able to get a struct page back from such an mmap is > a feature. Yes, that's clear. What we're discussing is whether gup_fast and pup_fast also obey this, or fall over and can give you the struct page that's backing the dma_mmap_* memory. Since the _fast variant doesn't check for vma->vm_flags, and afaict that's the only thing which closes this gap. And like you restate, that would be a bit a problem. So where's that check which Jason&me aren't spotting? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
