Hello,
this is incremental against current -mm.
The earlier patchset fixed the fctx->orig memleak but as I thought
during review, there was a further leak in fctx->new and Mike promptly
fixed it too. I've been running a reproducer and there's no further
memleak when the uffd is closed by the parent while fork() blocks
waiting for the event to be received.
In addition I found a potential stale pointer in MADV_DONTNEED if
userfaultfd_remove has to block and releases the mmap_sem in the
process. This patch revalidates the vma and fixes the
race. Unfortunately calling userfaultfd_remove last is not ok as
explained in the commit.
A "make" run from the directory selftests/vm/ independently started to
fail in v4.11 trying to write executables to the root directory.
That's not very friendly because it worked before, but it's easy to
fix and the last patch corrects this behavior in the vm/Makefile.
Andrea Arcangeli (2):
userfaultfd: non-cooperative: userfaultfd_remove revalidate vma in
MADV_DONTNEED
userfaultfd: selftest: vm: allow to build in vm/ directory
Mike Rapoport (1):
userfaultfd: non-cooperative: fix fork fctx->new memleak
fs/userfaultfd.c | 18 ++++++++++-----
include/linux/userfaultfd_k.h | 7 +++---
mm/madvise.c | 44 ++++++++++++++++++++++++++++++++++---
tools/testing/selftests/vm/Makefile | 4 ++++
4 files changed, 60 insertions(+), 13 deletions(-)
--
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>
