Hello Richard, On Tue, May 19, 2015 at 11:59:42PM +0200, Richard Weinberger wrote: > On Tue, May 19, 2015 at 11:38 PM, Andrew Morton > <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, 14 May 2015 19:30:57 +0200 Andrea Arcangeli <aarcange@xxxxxxxxxx> wrote: > > > >> This is the latest userfaultfd patchset against mm-v4.1-rc3 > >> 2015-05-14-10:04. > > > > It would be useful to have some userfaultfd testcases in > > tools/testing/selftests/. Partly as an aid to arch maintainers when > > enabling this. And also as a standalone thing to give people a > > practical way of exercising this interface. > > > > What are your thoughts on enabling userfaultfd for other architectures, > > btw? Are there good use cases, are people working on it, etc? > > UML is using SIGSEGV for page faults. > i.e. the UML processes receives a SIGSEGV, learns the faulting address > from the mcontext > and resolves the fault by installing a new mapping. > > If userfaultfd is faster that the SIGSEGV notification it could speed > up UML a bit. > For UML I'm only interested in the notification, not the resolving > part. The "missing" > data is present, only a new mapping is needed. No copy of data. > > Andrea, what do you think? I think you need some kind of UFFDIO_MPROTECT ioctl that is the same ioctl wrprotect tracking also needs. At the moment we focused the future plans mostly on wrprotection tracking but it could be extended to protnone tracking, either with the same feature flag as wrprotection (with a generic UFFDIO_MPROTECT) or with two separate feature flags and two separate ioctl. Your pages are not missing, like in the postcopy live snapshotting case the pages are not missing. The userfaultfd memory protection ioctl will not modify the VMA, but it'll just selectively mark pte/trans_huge_pmd wrprotected/protnone in order to get the faults. In the case of postcopy live snapshotting a single ioctl call will mark the entire guest address space readonly. For live snapshotting the fault resolution is a no brainer: when you get the fault the page is still readable and it just needs to be copied off by the live snapshotting thread to a different location, and then the UFFDIO_MPROTECT will be called again to make the page writable and wake the blocked fault. For the protnone, you need to modify the page before waking the blocked userfault, you can't just remove the protnone or other threads could modify it (if there are other threads). You'd need a further ioctl to copy the page off to a different place by using its kernel address (the userland address is not mapped) and copy it back to overwrite the original page. Alternatively once we extend the handle_userfault to tmpfs you could map the page in two virtual mappings and track the faults in one mapping (where the tracked app runs) and read/write the page contents in the other mapping that isn't tracked by the userfault. These are the first thoughts that comes to mind without knowing exactly what you need to do after you get the fault address, and without knowing exactly why you need to mark the region PROT_NONE. There will be some complications in adding the wrprotection/protnone feature: if faults could already happen when the wrprotect/protnone is armed, the handle_userfault() could be invoked in a retry-fault, that is not ok without allowing the userfault to return VM_FAULT_RETRY even during a refault (i.e. FAULT_FLAG_TRIED set but FAULT_FLAG_ALLOW_RETRY not set). The invariants of vma->vm_page_prot and pte/trans_huge_pmd permissions must also not break anywhere. These are the two main reasons why these features that requires to flip protection bits are left implemented later and made visible later with uffdio_api.feature flags and/or through uffdio_register.ioctl during UFFDIO_REGISTER. -- 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>