RE: [RFC PATCH 0/5] userfaultfd: non-cooperative: syncronous events

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: owner-linux-mm@xxxxxxxxx [mailto:owner-linux-mm@xxxxxxxxx] On
> Behalf Of Mike Rapoport
> Sent: Tuesday, June 27, 2017 9:40 AM
> To: Andrea Arcangeli <aarcange@xxxxxxxxxx>
> Cc: Pavel Emelyanov <xemul@xxxxxxxxxxxxx>; linux-mm <linux-
> mm@xxxxxxxxx>
> Subject: Re: [RFC PATCH 0/5] userfaultfd: non-cooperative: syncronous
events
> 
> 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?
> 
I have a use case for this feature exactly like what you have described. The
process should be suspended until the event has been handled. I would like
to test this if there is a rebased patchset out there somewhere? I'm using
4.13.0_rc3 from
https://kernel.googlesource.com/pub/scm/linux/kernel/git/andrea/aa.git

I wasn't able to apply the patches without heavy modification (mostly patch
3/5).

Thanks for the work on this.
> > 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>

--
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>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]
  Powered by Linux