On Tue, 16 Mar 2021, Peter Xu wrote: > > I'm curious whether it's okay to expand MREMAP_DONTUNMAP to PFNMAP too.. > E.g. vfio maps device MMIO regions with both VM_DONTEXPAND|VM_PFNMAP, to me it > makes sense to allow the userspace to get such MMIO region remapped/duplicated > somewhere else as long as the size won't change. With the strict check as > above we kill all those possibilities. > > Though in that case we'll still need commits like cd544fd1dc92 to protect any > customized ->mremap() when they're not supported. It would take me many hours to arrive at a conclusion on that: I'm going to spend the time differently, and let whoever ends up wanting MREMAP_DONTUNMAP on a VM_PFNMAP area research the safety of that for existing users. I did look to see what added VM_PFNMAP to the original VM_DONTEXPAND: v2.6.15 commit 4d7672b46244abffea1953e55688c0ea143dd617 Author: Linus Torvalds <torvalds@xxxxxxxxxxx> Date: Fri Dec 16 10:21:23 2005 -0800 Make sure we copy pages inserted with "vm_insert_page()" on fork The logic that decides that a fork() might be able to avoid copying a VM area when it can be re-created by page faults didn't know about the new vm_insert_page() case. Also make some things a bit more anal wrt VM_PFNMAP. Pointed out by Hugh Dickins <hugh@xxxxxxxxxxx> Signed-off-by: Linus Torvalds <torvalds@xxxxxxxx> So apparently I do bear some anal responsibility. My concern seems to have been that in those days an unexpected page fault in a special driver area would end up allocating an anonymous page, which would never get freed later. Nowadays it looks like there's a SIGBUS for the equivalent situation. So probably VM_DONTEXPAND is less important than it was, and the additional VM_PFNMAP safety net no longer necessary, and you could strip it out of the old size check and Brian's new dontunmap check. But I give no guarantee: I don't know VM_PFNMAP users at all well. Hugh
