From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org,willy@infradead.org,vbabka@kernel.org,surenb@google.com,stable@vger.kernel.org,sourabhjain@linux.ibm.com,rppt@kernel.org,ritesh.list@gmail.com,mhocko@suse.com,luizcap@redhat.com,ljs@kernel.org,liam@infradead.org,david@kernel.org,aboorvad@linux.ibm.com,akpm@linux-foundation.org
Subject: + mm-util-dont-read-__page_2-for-order-1-folios-in-snapshot_page.patch added to mm-hotfixes-unstable branch
Date: Wed, 08 Jul 2026 13:56:52 -0700 [thread overview]
Message-ID: <20260708205653.14D251F000E9@smtp.kernel.org> (raw)
The patch titled
Subject: mm/util: don't read __page_2 for order-1 folios in snapshot_page()
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
mm-util-dont-read-__page_2-for-order-1-folios-in-snapshot_page.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-util-dont-read-__page_2-for-order-1-folios-in-snapshot_page.patch
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days
------------------------------------------------------
From: Aboorva Devarajan <aboorvad@linux.ibm.com>
Subject: mm/util: don't read __page_2 for order-1 folios in snapshot_page()
Date: Thu, 9 Jul 2026 01:49:54 +0530
snapshot_page() currently reads __page_2 after checking nr_pages > 1, but
it should only do so when nr_pages > 2.
If an order-1 folio is allocated at the end of a vmemmap section,
__page_2 will not exist and reading it will cause a fault.
During DLPAR memory remove on a 22 TB ppc64le LPAR, snapshot_page() oopsed
on the page isolation path while reading an order-1 folio's __page_2 from
an adjacent absent section (unmapped vmemmap).
Fix this to avoid reading memmap that doesn't exist (e.g., a vmemmap
hole).
Link: https://lore.kernel.org/20260708201954.686111-1-aboorvad@linux.ibm.com
Fixes: 31a31da8a618 ("mm: move _pincount in folio to page[2] on 32bit")
Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Reported-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Reviewed-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Luiz Capitulino <luizcap@redhat.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: <stable@vger.kernel.org> # v6.15+
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/util.c~mm-util-dont-read-__page_2-for-order-1-folios-in-snapshot_page
+++ a/mm/util.c
@@ -1353,7 +1353,7 @@ again:
if (ps->idx < MAX_FOLIO_NR_PAGES) {
memcpy(&ps->folio_snapshot, foliop, 2 * sizeof(struct page));
nr_pages = folio_nr_pages(&ps->folio_snapshot);
- if (nr_pages > 1)
+ if (nr_pages > 2)
memcpy(&ps->folio_snapshot.__page_2, &foliop->__page_2,
sizeof(struct page));
set_ps_flags(ps, foliop, page);
_
Patches currently in -mm which might be from aboorvad@linux.ibm.com are
mm-util-dont-read-__page_2-for-order-1-folios-in-snapshot_page.patch
next reply other threads:[~2026-07-08 20:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 20:56 Andrew Morton [this message]
2026-07-08 22:06 ` + mm-util-dont-read-__page_2-for-order-1-folios-in-snapshot_page.patch added to mm-hotfixes-unstable branch Matthew Wilcox
2026-07-09 0:22 ` Andrew Morton
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=20260708205653.14D251F000E9@smtp.kernel.org \
--to=akpm@linux-foundation.org \
--cc=aboorvad@linux.ibm.com \
--cc=david@kernel.org \
--cc=liam@infradead.org \
--cc=ljs@kernel.org \
--cc=luizcap@redhat.com \
--cc=mhocko@suse.com \
--cc=mm-commits@vger.kernel.org \
--cc=ritesh.list@gmail.com \
--cc=rppt@kernel.org \
--cc=sourabhjain@linux.ibm.com \
--cc=stable@vger.kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.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