On Wed, Nov 4, 2020 at 5:21 PM Christoph Hellwig hch@infradead.org 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