linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Simek <monstr@monstr.eu>, Mike Rapoport <rppt@kernel.org>,
	Mike Rapoport <rppt@linux.ibm.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: [PATCH 1/4] mm/page_alloc: always initialize memory map for the holes
Date: Wed, 14 Jul 2021 15:37:36 +0300	[thread overview]
Message-ID: <20210714123739.16493-2-rppt@kernel.org> (raw)
In-Reply-To: <20210714123739.16493-1-rppt@kernel.org>

From: Mike Rapoport <rppt@linux.ibm.com>

Currently memory map for the holes is initialized only when SPARSEMEM
memory model is used. Yet, even with FLATMEM there could be holes in the
physical memory layout that have memory map entries.

For instance, the memory reserved using e820 API on i386 or
"reserved-memory" nodes in device tree would not appear in memblock.memory
and hence the struct pages for such holes will be skipped during memory map
initialization.

These struct pages will be zeroed because the memory map for FLATMEM
systems is allocated with memblock_alloc_node() that clears the allocated
memory. While zeroed struct pages do not cause immediate problems, the
correct behaviour is to initialize every page using __init_single_page().
Besides, enabling page poison for FLATMEM case will trigger
PF_POISONED_CHECK() unless the memory map is properly initialized.

Make sure init_unavailable_range() is called for both SPARSEMEM and FLATMEM
so that struct pages representing memory holes would appear as PG_Reserved
with any memory layout.

Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
 mm/page_alloc.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 3b97e17806be..878d7af4403d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6624,7 +6624,6 @@ static void __meminit zone_init_free_lists(struct zone *zone)
 	}
 }
 
-#if !defined(CONFIG_FLATMEM)
 /*
  * Only struct pages that correspond to ranges defined by memblock.memory
  * are zeroed and initialized by going through __init_single_page() during
@@ -6669,13 +6668,6 @@ static void __init init_unavailable_range(unsigned long spfn,
 		pr_info("On node %d, zone %s: %lld pages in unavailable ranges",
 			node, zone_names[zone], pgcnt);
 }
-#else
-static inline void init_unavailable_range(unsigned long spfn,
-					  unsigned long epfn,
-					  int zone, int node)
-{
-}
-#endif
 
 static void __init memmap_init_zone_range(struct zone *zone,
 					  unsigned long start_pfn,
-- 
2.28.0


  reply	other threads:[~2021-07-14 12:37 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-14 12:37 [PATCH 0/4] mm: ensure consistency of memory map poisoning Mike Rapoport
2021-07-14 12:37 ` Mike Rapoport [this message]
2021-07-31 16:56   ` [PATCH 1/4] mm/page_alloc: always initialize memory map for the holes Guenter Roeck
2021-07-31 18:30     ` Mike Rapoport
2021-07-31 19:11       ` Guenter Roeck
2021-08-25 12:11   ` David Hildenbrand
2021-07-14 12:37 ` [PATCH 2/4] microblaze: simplify pte_alloc_one_kernel() Mike Rapoport
2021-08-25 10:09   ` Michal Simek
2021-08-25 12:13   ` David Hildenbrand
2021-07-14 12:37 ` [PATCH 3/4] mm: introduce memmap_alloc() to unify memory map allocation Mike Rapoport
2021-07-14 22:32   ` Andrew Morton
2021-07-15  6:10     ` Mike Rapoport
2021-07-14 12:37 ` [PATCH 4/4] memblock: stop poisoning raw allocations Mike Rapoport
2021-07-31 17:13   ` Joe Perches
2021-08-03  7:58     ` Mike Rapoport
2021-08-03 16:19       ` Joe Perches

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=20210714123739.16493-2-rppt@kernel.org \
    --to=rppt@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=monstr@monstr.eu \
    --cc=rppt@linux.ibm.com \
    /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;
as well as URLs for NNTP newsgroup(s).