Re: [PATCH v5 0/6] Use killable vma write locking in most places

From: Andrew Morton

Date: Fri Mar 27 2026 - 12:48:48 EST


On Thu, 26 Mar 2026 01:08:30 -0700 Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote:

> 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.

Thanks, I added this to mm-new.

It doesn't appear to fix anything and it has no
appreciable&measured performance benefits, so I just broke my own rule.

Weasel words: Lorenzo would like it in 7.0, unreviewed patches in
mm-unstable&mm-new are down to 62 and I'm a sucker for nice patchsets.

Three of your patches lack review tags so now it's 65!