Use killable vma write locking in most places
| From: | Suren Baghdasaryan <surenb-AT-google.com> | |
| To: | akpm-AT-linux-foundation.org | |
| Subject: | [PATCH v5 0/6] Use killable vma write locking in most places | |
| Date: | Thu, 26 Mar 2026 01:08:30 -0700 | |
| Message-ID: | <20260326080836.695207-1-surenb@google.com> | |
| Cc: | willy-AT-infradead.org, david-AT-kernel.org, ziy-AT-nvidia.com, matthew.brost-AT-intel.com, joshua.hahnjy-AT-gmail.com, rakie.kim-AT-sk.com, byungchul-AT-sk.com, gourry-AT-gourry.net, ying.huang-AT-linux.alibaba.com, apopple-AT-nvidia.com, lorenzo.stoakes-AT-oracle.com, baolin.wang-AT-linux.alibaba.com, Liam.Howlett-AT-oracle.com, npache-AT-redhat.com, ryan.roberts-AT-arm.com, dev.jain-AT-arm.com, baohua-AT-kernel.org, lance.yang-AT-linux.dev, vbabka-AT-suse.cz, jannh-AT-google.com, rppt-AT-kernel.org, mhocko-AT-suse.com, pfalcato-AT-suse.de, kees-AT-kernel.org, maddy-AT-linux.ibm.com, npiggin-AT-gmail.com, mpe-AT-ellerman.id.au, chleroy-AT-kernel.org, borntraeger-AT-linux.ibm.com, frankja-AT-linux.ibm.com, imbrenda-AT-linux.ibm.com, hca-AT-linux.ibm.com, gor-AT-linux.ibm.com, agordeev-AT-linux.ibm.com, svens-AT-linux.ibm.com, gerald.schaefer-AT-linux.ibm.com, linux-mm-AT-kvack.org, linuxppc-dev-AT-lists.ozlabs.org, kvm-AT-vger.kernel.org, linux-kernel-AT-vger.kernel.org, linux-s390-AT-vger.kernel.org, surenb-AT-google.com | |
| Archive-link: | Article |
Now that we have vma_start_write_killable() we can replace most of the
vma_start_write() calls with it, improving reaction time to the kill
signal.
There are several places which are left untouched by this patchset:
1. free_pgtables() because function should free page tables even if a
fatal signal is pending.
2. userfaultd code, where some paths calling vma_start_write() can
handle EINTR and some can't without a deeper code refactoring.
3. mpol_rebind_mm() which is used by cpusset controller for migrations
and operates on a remote mm. Incomplete operations here would result
in an inconsistent cgroup state.
4. vm_flags_{set|mod|clear} require refactoring that involves moving
vma_start_write() out of these functions and replacing it with
vma_assert_write_locked(), then callers of these functions should
lock the vma themselves using vma_start_write_killable() whenever
possible.
Changes since v4 [1]:
- added Reviewed-by, per Barry Song and Lorenzo Stoakes (wherever the code
stayed the same)
- split patch 2 into 3 parts, per Lorenzo Stoakes
- converted vma_start_write() in mseal_apply(), per Sashiko
- changed vma_start_write_killable() error handling in
set_mempolicy_home_node(), per Lorenzo Stoakes
- added comment why mm->locked_vm is fine even when we exit early,
per Sashiko
- moved vma locking before vrm_calc_charge() in move_vma(), per Sashiko
and Lorenzo Stoakes
- set give_up_on_oom on error in vma_merge_existing_range() to propagate
the error, per Lorenzo Stoakes
- moved validate_mm() out of the error path in expand_upwards(),
per Lorenzo Stoakes
- dropped the patch changing S390 error handling, per Sashiko and
Lorenzo Stoakes
- reworked error handling in clear_refs_write(), per Lorenzo Stoakes
- uninlined process_vma_walk_lock() while changing its return type,
per Lorenzo Stoakes
[1] https://lore.kernel.org/all/20260322054309.898214-1-suren...
Suren Baghdasaryan (6):
mm/vma: cleanup error handling path in vma_expand()
mm: use vma_start_write_killable() in mm syscalls
mm/khugepaged: use vma_start_write_killable() in collapse_huge_page()
mm/vma: use vma_start_write_killable() in vma operations
mm: use vma_start_write_killable() in process_vma_walk_lock()
KVM: PPC: use vma_start_write_killable() in
kvmppc_memslot_page_merge()
arch/powerpc/kvm/book3s_hv_uvmem.c | 5 +-
fs/proc/task_mmu.c | 12 +--
mm/khugepaged.c | 5 +-
mm/madvise.c | 4 +-
mm/memory.c | 2 +
mm/mempolicy.c | 12 ++-
mm/mlock.c | 28 ++++--
mm/mprotect.c | 5 +-
mm/mremap.c | 8 +-
mm/mseal.c | 5 +-
mm/pagewalk.c | 22 +++--
mm/vma.c | 146 +++++++++++++++++++++--------
mm/vma_exec.c | 6 +-
13 files changed, 190 insertions(+), 70 deletions(-)
base-commit: e53c9040ab1b738dd2c83b57558f141902caaf4f
--
2.53.0.1018.g2bb0e51243-goog
