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(-)
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-surenb@google.com/
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
On Thu, 26 Mar 2026 01:08:30 -0700 Suren Baghdasaryan <surenb@google.com> 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!
On Fri, 27 Mar 2026 09:47:38 -0700 Andrew Morton <akpm@linux-foundation.org> wrote: > Three of your patches lack review tags so now it's 65! Three is now zero, thanks Lorenzo.
On Fri, Mar 27, 2026 at 10:03 AM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Fri, 27 Mar 2026 09:47:38 -0700 Andrew Morton <akpm@linux-foundation.org> wrote: > > > Three of your patches lack review tags so now it's 65! > > Three is now zero, thanks Lorenzo. I just finished fixups for issues Sashiko flagged. They are pretty small but important. Testing them right now and running Sashiko locally. Once done I'll post v6 and will ask Lorenzo to re-review those specific changes. Sorry Lorenzo, I'll point out the specific changes I had to make and will try to make it easy for you. Thanks, Suren.
On Fri, Mar 27, 2026 at 10:32:27AM -0700, Suren Baghdasaryan wrote: > On Fri, Mar 27, 2026 at 10:03 AM Andrew Morton > <akpm@linux-foundation.org> wrote: > > > > On Fri, 27 Mar 2026 09:47:38 -0700 Andrew Morton <akpm@linux-foundation.org> wrote: > > > > > Three of your patches lack review tags so now it's 65! > > > > Three is now zero, thanks Lorenzo. > > I just finished fixups for issues Sashiko flagged. They are pretty > small but important. Testing them right now and running Sashiko > locally. Once done I'll post v6 and will ask Lorenzo to re-review > those specific changes. Sorry Lorenzo, I'll point out the specific > changes I had to make and will try to make it easy for you. No worries :) Could you send to ljs@kernel.org on the respin? Sorry to nag about it but my email more and more set up for that and makes my life a wee bit easier :>) > Thanks, > Suren. Cheers, Lorenzo
On Fri, Mar 27, 2026 at 10:37 AM Lorenzo Stoakes (Oracle) <ljs@kernel.org> wrote: > > On Fri, Mar 27, 2026 at 10:32:27AM -0700, Suren Baghdasaryan wrote: > > On Fri, Mar 27, 2026 at 10:03 AM Andrew Morton > > <akpm@linux-foundation.org> wrote: > > > > > > On Fri, 27 Mar 2026 09:47:38 -0700 Andrew Morton <akpm@linux-foundation.org> wrote: > > > > > > > Three of your patches lack review tags so now it's 65! > > > > > > Three is now zero, thanks Lorenzo. > > > > I just finished fixups for issues Sashiko flagged. They are pretty > > small but important. Testing them right now and running Sashiko > > locally. Once done I'll post v6 and will ask Lorenzo to re-review > > those specific changes. Sorry Lorenzo, I'll point out the specific > > changes I had to make and will try to make it easy for you. > > No worries :) > > Could you send to ljs@kernel.org on the respin? Sorry to nag about it but my > email more and more set up for that and makes my life a wee bit easier :>) Absolutely. Thanks for the reminder. > > > Thanks, > > Suren. > > Cheers, Lorenzo
On Fri, Mar 27, 2026 at 10:38 AM Suren Baghdasaryan <surenb@google.com> wrote: > > On Fri, Mar 27, 2026 at 10:37 AM Lorenzo Stoakes (Oracle) > <ljs@kernel.org> wrote: > > > > On Fri, Mar 27, 2026 at 10:32:27AM -0700, Suren Baghdasaryan wrote: > > > On Fri, Mar 27, 2026 at 10:03 AM Andrew Morton > > > <akpm@linux-foundation.org> wrote: > > > > > > > > On Fri, 27 Mar 2026 09:47:38 -0700 Andrew Morton <akpm@linux-foundation.org> wrote: > > > > > > > > > Three of your patches lack review tags so now it's 65! > > > > > > > > Three is now zero, thanks Lorenzo. > > > > > > I just finished fixups for issues Sashiko flagged. They are pretty > > > small but important. Testing them right now and running Sashiko > > > locally. Once done I'll post v6 and will ask Lorenzo to re-review > > > those specific changes. Sorry Lorenzo, I'll point out the specific > > > changes I had to make and will try to make it easy for you. > > > > No worries :) > > > > Could you send to ljs@kernel.org on the respin? Sorry to nag about it but my > > email more and more set up for that and makes my life a wee bit easier :>) > > Absolutely. Thanks for the reminder. Doh! Just noticed git send-email doing this: (body) Adding cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> from line 'Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>' But it should also land in your kernel.org mailbox. Just posted v6 at: https://lore.kernel.org/all/20260327205457.604224-1-surenb@google.com/ Lorenzo, please see the cover letter where I list per-patch changes. 3 patches not listed there were unchanged. That should help a bit with re-reviewing them. Thank you! > > > > > > Thanks, > > > Suren. > > > > Cheers, Lorenzo
-cc old email
(Gentle reminder to please send all new stuff to ljs@kernel.org - at some
point I'm going to set a rule to ignore kernel mail sent to the old address
so, if you need a response you should send to the new :)
On Thu, Mar 26, 2026 at 01:08:30AM -0700, Suren Baghdasaryan 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.
>
> 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-surenb@google.com/
>
> 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
>
On Thu, Mar 26, 2026 at 2:18 AM Lorenzo Stoakes (Oracle) <ljs@kernel.org> wrote:
>
> -cc old email
>
> (Gentle reminder to please send all new stuff to ljs@kernel.org - at some
> point I'm going to set a rule to ignore kernel mail sent to the old address
> so, if you need a response you should send to the new :)
Ack, sorry about that and thanks for all the reviews, Lorenzo!
I noticed Sashiko's concerns at [1] and a number of them are false
positives but I see at least one new claim which might be legit. I'll
check if it holds water.
[1] https://sashiko.dev/#/patchset/20260326080836.695207-1-surenb%40google.com
>
>
> On Thu, Mar 26, 2026 at 01:08:30AM -0700, Suren Baghdasaryan 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.
> >
> > 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-surenb@google.com/
> >
> > 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
> >
+cc Roman On Thu, Mar 26, 2026 at 11:24:35AM -0700, Suren Baghdasaryan wrote: > On Thu, Mar 26, 2026 at 2:18 AM Lorenzo Stoakes (Oracle) <ljs@kernel.org> wrote: > > > > -cc old email > > > > (Gentle reminder to please send all new stuff to ljs@kernel.org - at some > > point I'm going to set a rule to ignore kernel mail sent to the old address > > so, if you need a response you should send to the new :) > > Ack, sorry about that and thanks for all the reviews, Lorenzo! > > I noticed Sashiko's concerns at [1] and a number of them are false > positives but I see at least one new claim which might be legit. I'll > check if it holds water. > > [1] https://sashiko.dev/#/patchset/20260326080836.695207-1-surenb%40google.com > Is worth letting Roman know which are valid and not, as that's useful information for refining the prompts etc. Cheers! Lorenzo
© 2016 - 2026 Red Hat, Inc.