Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1567128

Re: [RFC PATCH 0/5] userfaultfd: non-cooperative: better tracking for mapping changes

From "Hillf Danton" <hillf.zj@alibaba-inc.com>
Newsgroups linux.kernel
Subject Re: [RFC PATCH 0/5] userfaultfd: non-cooperative: better tracking for mapping changes
Date 2017-01-26 07:00 +0100
Message-ID <t3Lge-3vx-11@gated-at.bofh.it> (permalink)
References <t39ND-4ZI-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On January 24, 2017 9:52 PM Mike Rapoport wrote: 
> Hi,
> 
> These patches try to address issues I've encountered during integration of
> userfaultfd with CRIU.
> Previously added userfaultfd events for fork(), madvise() and mremap()
> unfortunately do not cover all possible changes to a process virtual memory
> layout required for uffd monitor.
> When one or more VMAs is removed from the process mm, the external uffd
> monitor has no way to detect those changes and will attempt to fill the
> removed regions with userfaultfd_copy.
> Another problematic event is the exit() of the process. Here again, the
> external uffd monitor will try to use userfaultfd_copy, although mm owning
> the memory has already gone.
> 
> The first patch in the series is a minor cleanup and it's not strictly
> related to the rest of the series.
> 
> The patches 2 and 3 below add UFFD_EVENT_UNMAP and UFFD_EVENT_EXIT to allow
> the uffd monitor track changes in the memory layout of a process.
> 
> The patches 4 and 5 amend error codes returned by userfaultfd_copy to make
> the uffd monitor able to cope with races that might occur between delivery
> of unmap and exit events and outstanding userfaultfd_copy's.
> 
> The patches are agains current -mm tree.
> 
> Mike Rapoport (5):
>   mm: call vm_munmap in munmap syscall instead of using open coded version
>   userfaultfd: non-cooperative: add event for memory unmaps
>   userfaultfd: non-cooperative: add event for exit() notification
>   userfaultfd: mcopy_atomic: return -ENOENT when no compatible VMA found
>   userfaultfd_copy: return -ENOSPC in case mm has gone
> 
>  arch/tile/mm/elf.c               |  2 +-
>  arch/x86/entry/vdso/vma.c        |  2 +-
>  arch/x86/mm/mpx.c                |  2 +-
>  fs/aio.c                         |  2 +-
>  fs/proc/vmcore.c                 |  4 +-
>  fs/userfaultfd.c                 | 91 ++++++++++++++++++++++++++++++++++++++++
>  include/linux/mm.h               | 14 ++++---
>  include/linux/userfaultfd_k.h    | 25 +++++++++++
>  include/uapi/linux/userfaultfd.h |  8 +++-
>  ipc/shm.c                        |  6 +--
>  kernel/exit.c                    |  2 +
>  mm/mmap.c                        | 55 ++++++++++++++----------
>  mm/mremap.c                      | 23 ++++++----
>  mm/userfaultfd.c                 | 42 ++++++++++---------
>  mm/util.c                        |  5 ++-
>  15 files changed, 215 insertions(+), 68 deletions(-)
> 
> --
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

[RFC PATCH 0/5] userfaultfd: non-cooperative: better tracking for mapping changes Mike Rapoport <rppt@linux.vnet.ibm.com> - 2017-01-24 15:00 +0100
  Re: [RFC PATCH 0/5] userfaultfd: non-cooperative: better tracking for mapping changes "Hillf Danton" <hillf.zj@alibaba-inc.com> - 2017-01-26 07:00 +0100

csiph-web