All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Qian Cai <qcai@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Baoquan He <bhe@redhat.com>, David Hildenbrand <david@redhat.com>,
	Mel Gorman <mgorman@suse.de>, Michal Hocko <mhocko@kernel.org>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	stable@vger.kernel.org, Stephen Rothwell <sfr@canb.auug.org.au>,
	Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] mm: fix initialization of struct page for holes in memory layout
Date: Wed, 6 Jan 2021 10:05:53 +0200	[thread overview]
Message-ID: <20210106080553.GB1106298@kernel.org> (raw)
In-Reply-To: <67ef893f27551f80ecf49ef78c0ebc05d3e41b46.camel@redhat.com>

On Tue, Jan 05, 2021 at 01:45:37PM -0500, Qian Cai wrote:
> On Tue, 2021-01-05 at 10:24 +0200, Mike Rapoport wrote:
> > Hi,
> > 
> > On Mon, Jan 04, 2021 at 02:03:00PM -0500, Qian Cai wrote:
> > > On Wed, 2020-12-09 at 23:43 +0200, Mike Rapoport wrote:
> > > > From: Mike Rapoport <rppt@linux.ibm.com>
> > > > 
> > > > Interleave initialization of pages that correspond to holes with the
> > > > initialization of memory map, so that zone and node information will be
> > > > properly set on such pages.
> > > > 
> > > > Fixes: 73a6e474cb37 ("mm: memmap_init: iterate over memblock regions
> > > > rather
> > > > that check each PFN")
> > > > Reported-by: Andrea Arcangeli <aarcange@redhat.com>
> > > > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> > > 
> > > Reverting this commit on the top of today's linux-next fixed a crash while
> > > reading /proc/kpagecount on a NUMA server.
> > 
> > Can you please post the entire dmesg?
> 
> http://people.redhat.com/qcai/dmesg.txt
> 
> > Is it possible to get the pfn that triggered the crash?
> 
> Do you have any idea how to convert that fffffffffffffffe to pfn as it is always
> that address? I don't understand what that address is though. I tried to catch
> it from struct page pointer and page_address() without luck.

I think we trigger PF_POISONED_CHECK() in PageSlab(), then fffffffffffffffe
is "accessed" from VM_BUG_ON_PAGE().

It seems to me that we are not initializing struct pages for holes at the node
boundaries because zones are already clamped to exclude those holes.

Can you please try to see if the patch below will produce any useful info:
 
diff --git a/fs/proc/page.c b/fs/proc/page.c
index 4dcbcd506cb6..708f8211dcc0 100644
--- a/fs/proc/page.c
+++ b/fs/proc/page.c
@@ -66,10 +66,14 @@ static ssize_t kpagecount_read(struct file *file, char __user *buf,
 		 */
 		ppage = pfn_to_online_page(pfn);
 
-		if (!ppage || PageSlab(ppage) || page_has_type(ppage))
+		if (ppage && PagePoisoned(ppage)) {
+			pr_info("%s: pfn %lx is poisoned\n", __func__, pfn);
 			pcount = 0;
-		else
+		} else if (!ppage || PageSlab(ppage) || page_has_type(ppage)) {
+			pcount = 0;
+		} else {
 			pcount = page_mapcount(ppage);
+		}
 
 		if (put_user(pcount, out)) {
 			ret = -EFAULT;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 124b8c654ec6..1b3a37ace1b1 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6271,6 +6271,8 @@ static u64 __init init_unavailable_range(unsigned long spfn, unsigned long epfn,
 	unsigned long pfn;
 	u64 pgcnt = 0;
 
+	pr_info("%s: spfn: %lx, epfn: %lx, zone: %s, node: %d\n", __func__, spfn, epfn, zone_names[zone], node);
+
 	for (pfn = spfn; pfn < epfn; pfn++) {
 		if (!pfn_valid(ALIGN_DOWN(pfn, pageblock_nr_pages))) {
 			pfn = ALIGN_DOWN(pfn, pageblock_nr_pages)
 
> >  
> > > [ 8858.006726][T99897] BUG: unable to handle page fault for address:
> > > fffffffffffffffe
> > > [ 8858.014814][T99897] #PF: supervisor read access in kernel mode
> > > [ 8858.020686][T99897] #PF: error_code(0x0000) - not-present page
> > > [ 8858.026557][T99897] PGD 1371417067 P4D 1371417067 PUD 1371419067 PMD 0 
> > > [ 8858.033224][T99897] Oops: 0000 [#1] SMP KASAN NOPTI
> > > [ 8858.038710][T99897] CPU: 28 PID: 99897 Comm: proc01 Tainted:
> > > G           O      5.11.0-rc1-next-20210104 #1
> > > [ 8858.048515][T99897] Hardware name: HPE ProLiant DL385 Gen10/ProLiant
> > > DL385 Gen10, BIOS A40 03/09/2018
> > > [ 8858.057794][T99897] RIP: 0010:kpagecount_read+0x1be/0x5e0
> > > PageSlab at include/linux/page-flags.h:342
> > > (inlined by) kpagecount_read at fs/proc/page.c:69
> 

-- 
Sincerely yours,
Mike.

  reply	other threads:[~2021-01-06  8:06 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-09 21:43 [PATCH v2 0/2] mm: fix initialization of struct page for holes in memory layout Mike Rapoport
2020-12-09 21:43 ` [PATCH v2 1/2] mm: memblock: enforce overlap of memory.memblock and memory.reserved Mike Rapoport
2020-12-10  9:28   ` Greg KH
2020-12-14 10:11   ` David Hildenbrand
2020-12-14 11:12     ` Mike Rapoport
2020-12-14 11:18       ` David Hildenbrand
2020-12-14 13:58         ` Andrea Arcangeli
2020-12-09 21:43 ` [PATCH v2 2/2] mm: fix initialization of struct page for holes in memory layout Mike Rapoport
2020-12-10  1:51   ` Andrea Arcangeli
2020-12-10  9:29   ` Greg KH
2021-01-04 19:03   ` Qian Cai
2021-01-04 19:03     ` Qian Cai
2021-01-05  8:24     ` Mike Rapoport
2021-01-05 18:45       ` Qian Cai
2021-01-05 18:45         ` Qian Cai
2021-01-06  8:05         ` Mike Rapoport [this message]
2021-01-06 21:04           ` Qian Cai
2021-01-06 21:04             ` Qian Cai
2021-01-10 15:39             ` Mike Rapoport
2021-01-11 15:06               ` Qian Cai
2021-01-11 15:06                 ` Qian Cai
2021-01-11 17:47                 ` Mike Rapoport

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=20210106080553.GB1106298@kernel.org \
    --to=rppt@kernel.org \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-next@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@kernel.org \
    --cc=qcai@redhat.com \
    --cc=rppt@linux.ibm.com \
    --cc=sfr@canb.auug.org.au \
    --cc=stable@vger.kernel.org \
    --cc=vbabka@suse.cz \
    /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.