Re: [PATCH v2 2/3] mm: replace vma_start_write() with vma_start_write_killable()

["Liam R. Howlett" <Liam.Howlett@oracle.com>]

* Suren Baghdasaryan <surenb@google.com> [260217 16:03]:
> On Tue, Feb 17, 2026 at 11:19 AM Liam R. Howlett
> <Liam.Howlett@oracle.com> wrote:
> >
> > * Suren Baghdasaryan <surenb@google.com> [260217 11:33]:
> > > 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(-)
> > >

...

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

Cheers,
Liam

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