public inbox for patches@lists.linux.dev
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	patches@lists.linux.dev, Hugh Dickins <hughd@google.com>,
	stable@kernel.org, Andrew Morton <akpm@linux-foundation.org>,
	Matthew Wilcox <willy@infradead.org>,
	David Stevens <stevensd@chromium.org>,
	Peter Xu <peterx@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: [PATCH 6.4 24/28] mm/khugepaged: fix regression in collapse_file()
Date: Thu, 29 Jun 2023 20:44:12 +0200	[thread overview]
Message-ID: <20230629184152.832327871@linuxfoundation.org> (raw)
In-Reply-To: <20230629184151.888604958@linuxfoundation.org>

From: Hugh Dickins <hughd@google.com>

commit e8c716bc6812202ccf4ce0f0bad3428b794fb39c upstream.

There is no xas_pause(&xas) in collapse_file()'s main loop, at the points
where it does xas_unlock_irq(&xas) and then continues.

That would explain why, once two weeks ago and twice yesterday, I have
hit the VM_BUG_ON_PAGE(page != xas_load(&xas), page) since "mm/khugepaged:
fix iteration in collapse_file" removed the xas_set(&xas, index) just
before it: xas.xa_node could be left pointing to a stale node, if there
was concurrent activity on the file which transformed its xarray.

I tried inserting xas_pause()s, but then even bootup crashed on that
VM_BUG_ON_PAGE(): there appears to be a subtle "nextness" implicit in
xas_pause().

xas_next() and xas_pause() are good for use in simple loops, but not in
this one: xas_set() worked well until now, so use xas_set(&xas, index)
explicitly at the head of the loop; and change that VM_BUG_ON_PAGE() not
to need its own xas_set(), and not to interfere with the xa_state (which
would probably stop the crashes from xas_pause(), but I trust that less).

The user-visible effects of this bug (if VM_BUG_ONs are configured out)
would be data loss and data leak - potentially - though in practice I
expect it is more likely that a subsequent check (e.g. on mapping or on
nr_none) would notice an inconsistency, and just abandon the collapse.

Link: https://lore.kernel.org/linux-mm/f18e4b64-3f88-a8ab-56cc-d1f5f9c58d4@google.com/
Fixes: c8a8f3b4a95a ("mm/khugepaged: fix iteration in collapse_file")
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: stable@kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: David Stevens <stevensd@chromium.org>
Cc: Peter Xu <peterx@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 mm/khugepaged.c |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -1918,9 +1918,9 @@ static int collapse_file(struct mm_struc
 		}
 	} while (1);
 
-	xas_set(&xas, start);
 	for (index = start; index < end; index++) {
-		page = xas_next(&xas);
+		xas_set(&xas, index);
+		page = xas_load(&xas);
 
 		VM_BUG_ON(index != xas.xa_index);
 		if (is_shmem) {
@@ -1935,7 +1935,6 @@ static int collapse_file(struct mm_struc
 						result = SCAN_TRUNCATED;
 						goto xa_locked;
 					}
-					xas_set(&xas, index + 1);
 				}
 				if (!shmem_charge(mapping->host, 1)) {
 					result = SCAN_FAIL;
@@ -2071,7 +2070,7 @@ static int collapse_file(struct mm_struc
 
 		xas_lock_irq(&xas);
 
-		VM_BUG_ON_PAGE(page != xas_load(&xas), page);
+		VM_BUG_ON_PAGE(page != xa_load(xas.xa, index), page);
 
 		/*
 		 * We control three references to the page:



  parent reply	other threads:[~2023-06-29 18:48 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-29 18:43 [PATCH 6.4 00/28] 6.4.1-rc1 review Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 01/28] x86/microcode/AMD: Load late on both threads too Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 02/28] x86/smp: Make stop_other_cpus() more robust Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 03/28] x86/smp: Dont access non-existing CPUID leaf Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 04/28] x86/smp: Remove pointless wmb()s from native_stop_other_cpus() Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 05/28] x86/smp: Use dedicated cache-line for mwait_play_dead() Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 06/28] x86/smp: Cure kexec() vs. mwait_play_dead() breakage Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 07/28] cpufreq: amd-pstate: Make amd-pstate EPP driver name hyphenated Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 08/28] can: isotp: isotp_sendmsg(): fix return error fix on TX path Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 09/28] maple_tree: fix potential out-of-bounds access in mas_wr_end_piv() Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 10/28] mm: introduce new lock_mm_and_find_vma() page fault helper Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 11/28] mm: make the page fault mmap locking killable Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 12/28] arm64/mm: Convert to using lock_mm_and_find_vma() Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 13/28] powerpc/mm: " Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 14/28] mips/mm: " Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 15/28] riscv/mm: " Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 16/28] arm/mm: " Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 17/28] mm/fault: convert remaining simple cases to lock_mm_and_find_vma() Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 18/28] powerpc/mm: convert coprocessor fault " Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 19/28] mm: make find_extend_vma() fail if write lock not held Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 20/28] execve: expand new process stack manually ahead of time Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 21/28] mm: always expand the stack with the mmap write lock held Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 22/28] HID: wacom: Use ktime_t rather than int when dealing with timestamps Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 23/28] gup: add warning if some caller would seem to want stack expansion Greg Kroah-Hartman
2023-06-29 18:44 ` Greg Kroah-Hartman [this message]
2023-06-29 18:44 ` [PATCH 6.4 25/28] fbdev: fix potential OOB read in fast_imageblit() Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 26/28] HID: hidraw: fix data race on device refcount Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 27/28] HID: logitech-hidpp: add HIDPP_QUIRK_DELAYED_INIT for the T651 Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 28/28] Revert "thermal/drivers/mediatek: Use devm_of_iomap to avoid resource leak in mtk_thermal_probe" Greg Kroah-Hartman
2023-06-30  5:30 ` [PATCH 6.4 00/28] 6.4.1-rc1 review Naresh Kamboju
2023-06-30  5:52   ` Greg Kroah-Hartman
2023-06-30  6:16   ` Linus Torvalds
2023-06-30  6:29     ` Greg Kroah-Hartman
2023-06-30  6:56       ` Helge Deller
2023-06-30  6:29     ` Guenter Roeck
2023-06-30  6:33       ` Guenter Roeck
2023-06-30  6:33       ` Linus Torvalds
2023-06-30  6:47         ` Linus Torvalds
2023-06-30 22:51           ` Guenter Roeck
2023-07-01  1:24             ` Linus Torvalds
2023-07-01  2:49               ` Guenter Roeck
2023-07-01  4:22                 ` Linus Torvalds
2023-07-01  9:57                   ` Greg Kroah-Hartman
2023-07-01 10:32                   ` Max Filippov
2023-07-01 15:01                     ` Linus Torvalds
2023-06-30  6:51         ` Greg Kroah-Hartman
2023-06-30  6:28   ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230629184152.832327871@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=patches@lists.linux.dev \
    --cc=peterx@redhat.com \
    --cc=stable@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=stevensd@chromium.org \
    --cc=torvalds@linux-foundation.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox