All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: mm-commits@vger.kernel.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
Subject: Re: + mm-util-dont-read-__page_2-for-order-1-folios-in-snapshot_page.patch added to mm-hotfixes-unstable branch
Date: Wed, 8 Jul 2026 17:22:24 -0700	[thread overview]
Message-ID: <20260708172224.f919bee522da26d700cef447@linux-foundation.org> (raw)
In-Reply-To: <ak7J8oaLkNsWNOrx@casper.infradead.org>

On Wed, 8 Jul 2026 23:06:42 +0100 Matthew Wilcox <willy@infradead.org> wrote:

> On Wed, Jul 08, 2026 at 01:56:52PM -0700, Andrew Morton wrote:
> > 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>
> 
> You're taking my R-b without taking my rewording of the second
> paragraph?

I added your sentence.  Aboorva's info was potentially useful, absent a
Link: to a report,

      reply	other threads:[~2026-07-09  0:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-08 20:56 + mm-util-dont-read-__page_2-for-order-1-folios-in-snapshot_page.patch added to mm-hotfixes-unstable branch Andrew Morton
2026-07-08 22:06 ` Matthew Wilcox
2026-07-09  0:22   ` Andrew Morton [this message]

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=20260708172224.f919bee522da26d700cef447@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.