From: Greg Kroah-Hartman Date: Sun, 17 Sep 2023 06:10:39 +0000 (+0200) Subject: 6.5-stable patches X-Git-Tag: v5.10.195~21 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=9a5b9e60f989a8c9341452d37887073f21c4d997;p=thirdparty%2Fkernel%2Fstable-queue.git 6.5-stable patches added patches: vm-fix-move_vma-memory-accounting-being-off.patch --- diff --git a/queue-6.5/series b/queue-6.5/series index 1752ca8bf1b..cb0594d8d37 100644 --- a/queue-6.5/series +++ b/queue-6.5/series @@ -281,3 +281,4 @@ ixgbe-fix-timestamp-configuration-code.patch igb-clean-up-in-all-error-paths-when-enabling-sr-iov.patch net-renesas-rswitch-fix-unmasking-irq-condition.patch kcm-fix-error-handling-for-sock_dgram-in-kcm_sendmsg.patch +vm-fix-move_vma-memory-accounting-being-off.patch diff --git a/queue-6.5/vm-fix-move_vma-memory-accounting-being-off.patch b/queue-6.5/vm-fix-move_vma-memory-accounting-being-off.patch new file mode 100644 index 00000000000..d1f127352b8 --- /dev/null +++ b/queue-6.5/vm-fix-move_vma-memory-accounting-being-off.patch @@ -0,0 +1,54 @@ +From 3cec50490969afd4a76ccee441f747d869ccff77 Mon Sep 17 00:00:00 2001 +From: Linus Torvalds +Date: Sat, 16 Sep 2023 12:31:42 -0700 +Subject: vm: fix move_vma() memory accounting being off + +From: Linus Torvalds + +commit 3cec50490969afd4a76ccee441f747d869ccff77 upstream. + +Commit 408579cd627a ("mm: Update do_vmi_align_munmap() return +semantics") seems to have updated one of the callers of do_vmi_munmap() +incorrectly: it used to check for the error case (which didn't +change: negative means error). + +That commit changed the check to the success case (which did change: +before that commit, 0 was success, and 1 was "success and lock +downgraded". After the change, it's always 0 for success, and the lock +will have been released if requested). + +This didn't change any actual VM behavior _except_ for memory accounting +when 'VM_ACCOUNT' was set on the vma. Which made the wrong return value +test fairly subtle, since everything continues to work. + +Or rather - it continues to work but the "Committed memory" accounting +goes all wonky (Committed_AS value in /proc/meminfo), and depending on +settings that then causes problems much much later as the VM relies on +bogus statistics for its heuristics. + +Revert that one line of the change back to the original logic. + +Fixes: 408579cd627a ("mm: Update do_vmi_align_munmap() return semantics") +Reported-by: Christoph Biedl +Reported-bisected-and-tested-by: Michael Labiuk +Cc: Bagas Sanjaya +Cc: Liam R. Howlett +Link: https://lore.kernel.org/all/1694366957@msgid.manchmal.in-ulm.de/ +Signed-off-by: Linus Torvalds +Cc: Helge Deller +Signed-off-by: Greg Kroah-Hartman +--- + mm/mremap.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/mm/mremap.c ++++ b/mm/mremap.c +@@ -715,7 +715,7 @@ static unsigned long move_vma(struct vm_ + } + + vma_iter_init(&vmi, mm, old_addr); +- if (!do_vmi_munmap(&vmi, mm, old_addr, old_len, uf_unmap, false)) { ++ if (do_vmi_munmap(&vmi, mm, old_addr, old_len, uf_unmap, false) < 0) { + /* OOM: unable to split vma, just get accounts right */ + if (vm_flags & VM_ACCOUNT && !(flags & MREMAP_DONTUNMAP)) + vm_acct_memory(old_len >> PAGE_SHIFT);