On Wed, Feb 18, 2026 at 8:46 AM Liam R. Howlett <[email protected]> wrote: > > * Suren Baghdasaryan <[email protected]> [260217 16:03]: > > On Tue, Feb 17, 2026 at 11:19 AM Liam R. Howlett > > <[email protected]> wrote: > > > > > > * Suren Baghdasaryan <[email protected]> [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 <[email protected]> > > > > Signed-off-by: Suren Baghdasaryan <[email protected]> > > > > Reviewed-by: Ritesh Harjani (IBM) <[email protected]> # 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-
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/ > >
