On Tue, May 16, 2017 at 01:35:57PM +0300, Mike Rapoport wrote: > Hi, Any comments on this? Shall I repost without the "RFC" prefix? > 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>
