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 1752ca8bf1bc785fd2a882c6a5454409cfa440df..cb0594d8d3786965d765bf530d09351534b9d526 100644 (file)
--- 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 (file)
index 0000000..d1f1273
--- /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 <torvalds@linux-foundation.org>
+Date: Sat, 16 Sep 2023 12:31:42 -0700
+Subject: vm: fix move_vma() memory accounting being off
+
+From: Linus Torvalds <torvalds@linux-foundation.org>
+
+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 <linux-kernel.bfrz@manchmal.in-ulm.de>
+Reported-bisected-and-tested-by: Michael Labiuk <michael.labiuk@virtuozzo.com>
+Cc: Bagas Sanjaya <bagasdotme@gmail.com>
+Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
+Link: https://lore.kernel.org/all/1694366957@msgid.manchmal.in-ulm.de/
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);