OpenVZ / Virtuozzo kernel development (devel@openvz.org)
 help / color / mirror / Atom feed
* [Devel] [PATCH hci-8.1 0/8] mm: keep DMA-pinned MADV_DOEXEC memory working across exec
@ 2026-10-14 17:11 Konstantin Khorenko
  2026-10-14 17:11 ` [Devel] [PATCH hci-8.1 1/8] oracle/mm: fix VM_BUG_ON hit when preserving memory Konstantin Khorenko
                   ` (7 more replies)
  0 siblings, 8 replies; 17+ messages in thread
From: Konstantin Khorenko @ 2026-10-14 17:11 UTC (permalink / raw)
  To: Vasileios Almpanis, Andrey Drobyshev, Pavel Tikhomirov; +Cc: devel

VSTOR-149847: memory preserved across exec with MADV_DOEXEC loses its
connection to long-term pins (VFIO DMA, io_uring fixed buffers) after a
live-update exec, because the copy into the new mm write protects the
pages and the first write in the new image copies them away from the
pins. Applies on top of "mm, binfmt_elf: two fixes also posted to
mainline".
http://lore.virtuozzo.com/20261014-b4-prep-khorenko-vstor-149847-1-upstream-fixes-v1-0-7fde9ffbebe9@virtuozzo.com

Patches 1-3 are Oracle's fixes for that path, taken from UEK8 (uek8/u2)
as they are: the copy runs under the write lock of the old mm with
write_protect_seq held, and preserved PTEs of COW mappings are no longer
write protected.

Patches 4-6 fix what patch 3 leaves:
- 4: the preserved PTE stayed writable in both mms, which
  page_table_check catches on a debug kernel (kernel BUG at
  mm/page_table_check.c). Write protect both copies but keep
  PageAnonExclusive, so the first write in the new image reuses the
  page.
- 5: MMF_HAS_PINNED is carried to the new mm, otherwise a fork in the
  new image treats pinned pages as unpinned and separates them from
  their pins.
- 6: the preserved ranges of the old mm are zapped right after the copy;
  while the old mm lived, a page was exclusive in two mms and
  UFFDIO_MOVE could move its rmap to an anon_vma that is later freed.
  The zap runs on several threads, as the teardown of these ranges
  did before.

Patch 7 (Andrey) refuses a preserving exec while a CLONE_VM task outside
the thread group shares the old mm, and patch 8 is its selftest, which
also covers the pinned cases above. A kernel thread on the mm counts
too: with vhost in kthread mode, the vz10 default, QEMU has to reset the
vhost owner before a preserving exec.

Tested with the whole stack on release and debug kernels: the
MADV_DOEXEC selftests (including the allocation-failure sweep on the
debug kernel), gup_test, a Container start/exec/stop; no BUG, WARNING
or KASAN.

https://virtuozzo.atlassian.net/browse/VSTOR-150231

---
Andrey Drobyshev (2):
      exec: protect preserved memory against surviving shared-mm tasks
      selftests/mm: test memory preservation across exec

Anthony Yznaga (3):
      oracle/mm: fix VM_BUG_ON hit when preserving memory
      oracle/mm: hold the source mmap write lock when copying PTEs
      oracle/mm: do not write protect COW mappings when preserving across exec

Konstantin Khorenko (3):
      oracle/mm: write protect preserved PTEs but keep them exclusive
      oracle/mm: set MMF_HAS_PINNED on the mm receiving preserved pages
      oracle/mm: zap the preserved ranges of the old mm after copying them

 fs/exec.c                                 | 111 +++-
 include/linux/binfmts.h                   |   4 +-
 include/linux/mm.h                        |   1 +
 include/linux/mm_types.h                  |   4 +
 include/linux/rmap.h                      |   8 +-
 kernel/fork.c                             |  37 ++
 mm/memory.c                               |  93 +++-
 mm/mmap.c                                 |   7 +-
 tools/testing/selftests/mm/.gitignore     |   1 +
 tools/testing/selftests/mm/Makefile       |   1 +
 tools/testing/selftests/mm/doexec.c       | 814 ++++++++++++++++++++++++++++++
 tools/testing/selftests/mm/run_vmtests.sh |   4 +
 12 files changed, 1050 insertions(+), 35 deletions(-)
---
base-commit: 975b3d461d014d75dbc775f44a4758fb41996d09
change-id: 20261014-b4-prep-khorenko-vstor-149847-2-doexec-pinned-memory-51b0e4b50c5e

Best regards,
--  
Konstantin Khorenko <khorenko@virtuozzo.com>

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2026-10-14 17:35 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-14 17:11 [Devel] [PATCH hci-8.1 0/8] mm: keep DMA-pinned MADV_DOEXEC memory working across exec Konstantin Khorenko
2026-10-14 17:11 ` [Devel] [PATCH hci-8.1 1/8] oracle/mm: fix VM_BUG_ON hit when preserving memory Konstantin Khorenko
2026-10-14 17:16   ` no-reply
2026-10-14 17:11 ` [Devel] [PATCH hci-8.1 2/8] oracle/mm: hold the source mmap write lock when copying PTEs Konstantin Khorenko
2026-10-14 17:15   ` no-reply
2026-10-14 17:11 ` [Devel] [PATCH hci-8.1 3/8] oracle/mm: do not write protect COW mappings when preserving across exec Konstantin Khorenko
2026-10-14 17:20   ` no-reply
2026-10-14 17:11 ` [Devel] [PATCH hci-8.1 4/8] oracle/mm: write protect preserved PTEs but keep them exclusive Konstantin Khorenko
2026-10-14 17:18   ` no-reply
2026-10-14 17:11 ` [Devel] [PATCH hci-8.1 5/8] oracle/mm: set MMF_HAS_PINNED on the mm receiving preserved pages Konstantin Khorenko
2026-10-14 17:19   ` no-reply
2026-10-14 17:11 ` [Devel] [PATCH hci-8.1 6/8] oracle/mm: zap the preserved ranges of the old mm after copying them Konstantin Khorenko
2026-10-14 17:24   ` no-reply
2026-10-14 17:11 ` [Devel] [PATCH hci-8.1 7/8] exec: protect preserved memory against surviving shared-mm tasks Konstantin Khorenko
2026-10-14 17:24   ` no-reply
2026-10-14 17:11 ` [Devel] [PATCH hci-8.1 8/8] selftests/mm: test memory preservation across exec Konstantin Khorenko
2026-10-14 17:33   ` no-reply

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox