Hi, These patches add ability to generate userfaultfd events so that thier processing will be synchronized with the non-cooperative thread that caused the event. In the non-cooperative case userfaultfd resumes execution of the thread that caused an event when the notification is read() by the uffd monitor. In some cases, like, for example, madvise(MADV_REMOVE), it might be desirable to keep the thread that caused the event suspended until the uffd monitor had the event handled. The first two patches just shuffle the code a bit to make subsequent changes easier. The patches 3 and 4 create some unification in the way the threads are queued into waitqueues either after page fault or after a non-cooperative event. The fifth patch extends the userfaultfd API with an implementation of UFFD_EVENT_REMOVE_SYNC that allows to keep the thread that triggered UFFD_EVENT_REMOVE until the uffd monitor would not wake it explicitly. Mike Rapoport (5): userfaultfd: introduce userfault_init_waitqueue helper userfaultfd: introduce userfaultfd_should_wait helper userfaultfd: non-cooperative: generalize wake key structure userfaultfd: non-cooperative: use fault_pending_wqh for all events userfaultfd: non-cooperative: allow synchronous EVENT_REMOVE fs/userfaultfd.c | 205 ++++++++++++++++++++++++--------------- include/uapi/linux/userfaultfd.h | 11 +++ 2 files changed, 136 insertions(+), 80 deletions(-) -- 2.7.4 -- 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>
