On Thu, Feb 4, 2021 at 7:38 PM Jason Gunthorpe <jgg@xxxxxxxx> wrote: > > On Thu, Feb 04, 2021 at 06:16:27PM +0100, Daniel Vetter wrote: > > On Thu, Feb 4, 2021 at 5:13 PM Jason Gunthorpe <jgg@xxxxxxxx> wrote: > > > On Wed, Feb 03, 2021 at 10:19:48PM +0100, Daniel Vetter wrote: > > > > tldr; DMA buffers aren't normal memory, expecting that you can use > > > > them like that (like calling get_user_pages works, or that they're > > > > accounting like any other normal memory) cannot be guaranteed. > > > > > > > > Since some userspace only runs on integrated devices, where all > > > > buffers are actually all resident system memory, there's a huge > > > > temptation to assume that a struct page is always present and useable > > > > like for any more pagecache backed mmap. This has the potential to > > > > result in a uapi nightmare. > > > > > > > > To stop this gap require that DMA buffer mmaps are VM_SPECIAL, which > > > > blocks get_user_pages and all the other struct page based > > > > infrastructure for everyone. In spirit this is the uapi counterpart to > > > > the kernel-internal CONFIG_DMABUF_DEBUG. > > > > > > Fast gup needs the special flag set on the PTE as well.. Feels weird > > > to have a special VMA without also having special PTEs? > > > > There's kinda no convenient & cheap way to check for the pte_special > > flag. This here should at least catch accidental misuse, people > > building their own ptes we can't stop. Maybe we should exclude > > VM_MIXEDMAP to catch vm_insert_page in one of these. > > > > Hm looking at code I think we need to require VM_PFNMAP here to stop > > vm_insert_page. And looking at the various functions, that seems to be > > required (and I guess VM_IO is more for really funky architectures > > where io-space is somewhere else?). I guess I should check for > > VM_PFNMAP instead of VM_SPECIAL? > > Well, you said the goal was to block GUP usage, that won't happen > without the PTE special flag, at least on x86 > > So, really, what you are saying is all dmabuf users should always use > vmf_insert_pfn_prot() or something similar - and never insert_page/etc? > > It might make sense to check the vma flags in all the insert paths, eg > vm_insert_page() can't work with VMAs that should not have struct > pages in them (eg VM_SPECIAl, VM_PFNMAP, !VM_MIXEMAP if I understand > it right) Well that's what I've done, and it /looks/ like all the checks are there already, as long as we use VM_PFNMAP. vm_insert_page tries to auto-add VM_MIXEDMAP, but bails out with a BUG_ON if VM_PFNMAP is set. And all the vm_insert_pfn_prot/remap_pfn_range functions require (or set) VM_PFNMAP. 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). > At least as some VM debug option Seems to be there already unconditionally. -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
