Hello Evgeny, On Thu, Aug 11, 2016 at 04:51:30PM +0300, Evgeny Yakovlev wrote: > * 1. First fault is expected UFFD_PAGEFAULT_FLAG_WRITE set which we > resolve > * with zeropage What if you resolve it with bzero(4096);UFFDIO_COPY? Does the problem go away? If the zeropage is mapped by UFFDIO_ZEROPAGE, there's no way to turn that into a writable zeropage ever again because userfaultfd_writeprotect is basically a no-vma-mangling mmap_sem-read mprotect and it can't trigger faults. Instead a fault in do_wp_page is required to get rid of the zeropage and copy it off. If the problem goes away if you s/UFFDIO_ZEROPAGE/bzero(4096); UFFDIO_COPY/ as I would expect, there would be two ways to solve it: 1) forbid UFFDIO_ZEROPAGE and not return the UFFDIO_ZEROPAGE ioctl in uffdio_register.ioctls, if UFFDIO_REGISTER is called with uffdio_register.mode = ...WP|..MISSING so userland is aware it can't use that. 2) teach UFFDIO_WRITEPROTECT not just to mangle pagetables but also trigger a write fault on any zeropage if it's called with uffdio_writeprotect.mode without UFFDIO_WRITEPROTECT_MODE_WP being set. This will require a bit more work to fix. The latter would increase performance if not all zeropages needs to be turned writable. Feedback welcome on what solution would you prefer. Thanks, Andrea -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>