Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1567128
| 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 |
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 | Next — Previous in thread | Find similar | Unroll 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