Hello everyone, On Mon, Jun 16, 2014 at 01:12:41PM -0700, John Stultz wrote: > On Tue, Jun 3, 2014 at 7:57 AM, Johannes Weiner <hannes@xxxxxxxxxxx> wrote: > > That, however, truly is a separate virtual memory feature. Would it > > be possible for you to take MADV_FREE and MADV_REVIVE as a base and > > implement an madvise op that switches the no-page behavior of a VMA > > from zero-filling to SIGBUS delivery? > > I'll see if I can look into it if I get some time. However, I suspect > its more likely I'll just have to admit defeat on this one and let > someone else champion the effort. Interest and reviews have seemingly > dropped again here and with other work ramping up, I'm not sure if > I'll be able to justify further work on this. :( About adding an madvise op that switches the no-page behavior from zero-filling to SIGBUS delivery (right now only for anonymous vmas but we can evaluate to extend it) I've mostly completed the userfaultfd/madvise(MADV_USERFAULT) according to the design I described earlier. Like we discussed earlier that may fit the bill if extended to tmpfs? The first preliminary tests just passed last week. http://git.kernel.org/cgit/linux/kernel/git/andrea/aa.git/?h=userfault If userfaultfd() isn't instantiated by the process, it only sends a SIBGUS to the thread accessing the unmapped virtual address (handle_mm_faults returns VM_FAULT_SIGBUS). The address of the fault is then available in siginfo->si_addr. You strictly need a memory externalization thread opening the userfaultfd and speaking the userfaultfd protocol only if you need to access the memory also through syscalls or drivers doing GUP calls. This allows memory mapped in a secondary MMU for example to be externalized without a single change to the secondary MMU code. The userfault becomes invisible to handle_mm_fault/gup()/gup_fast/FOLL_NOWAIT etc.... The only requirement is that the memory externalization thread never accesses any memory in the MADV_USERFAULT marked regions (and if it does because of a bug, the deadlock should be quite apparent by simply checking the stack trace of the externalization thread blocked in handle_userfault(), sigkill will then clear it up :). If you close the userfaultfd the SIGBUS behavior will immediately return for the MADV_USERFAULT marked regions and any hung task waiting to be waken will get an immediate SIGBUS. -- 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>