On Wed, Feb 18, 2026 at 8:46 AM Liam R. Howlett [off-list ref] wrote:

* Suren Baghdasaryan [off-list ref] [260217 16:03]:

quoted

On Tue, Feb 17, 2026 at 11:19 AM Liam R. Howlett
[off-list ref] wrote:

quoted

* Suren Baghdasaryan [off-list ref] [260217 11:33]:

quoted

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 patch:

1. free_pgtables() because function should free page tables even if a
fatal signal is pending.

2. process_vma_walk_lock(), which requires changes in its callers and
will be handled in the next patch.

3. userfaultd code, where some paths calling vma_start_write() can
handle EINTR and some can't without a deeper code refactoring.

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.

Suggested-by: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> # powerpc
---
 arch/powerpc/kvm/book3s_hv_uvmem.c |  5 +-
 include/linux/mempolicy.h          |  5 +-
 mm/khugepaged.c                    |  5 +-
 mm/madvise.c                       |  4 +-
 mm/memory.c                        |  2 +
 mm/mempolicy.c                     | 23 ++++++--
 mm/mlock.c                         | 20 +++++--
 mm/mprotect.c                      |  4 +-
 mm/mremap.c                        |  4 +-
 mm/vma.c                           | 93 +++++++++++++++++++++---------
 mm/vma_exec.c                      |  6 +-
 11 files changed, 123 insertions(+), 48 deletions(-)

...

quoted

quoted

...

quoted

@@ -3089,7 +3120,7 @@ int expand_upwards(struct vm_area_struct *vma, unsigned long address)

Good luck testing this one.

Yeah... Any suggestions for tests I should use?

I think you have to either isolate it or boot parisc.

To boot parisc, you can use the debian hppa image [1].  The file is a
zip file which can be decompressed to a qcow2, initrd, and kernel.  You
can boot with qemu-system-hppa (debian has this in qemu-system-misc
package), there is a readme that has a boot line as well.

Building can be done using the cross-compiler tools for hppa [2] and the
make command with CROSS_COMPILE=<path>/bin/hppa64-linux-

Ah, I thought you were referring to the difficulty of finding specific
tests to verify this change but these instructions are helpful too.
Thanks!

Cheers,
Liam

[1]. https://people.debian.org/~gio/dqib/
[2]. https://cdn.kernel.org/pub/tools/crosstool/files/bin/x86_64/15.2.0/