All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Mike Rapoport <rppt@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Simek <monstr@monstr.eu>,
	Mike Rapoport <rppt@linux.ibm.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 1/4] mm/page_alloc: always initialize memory map for the holes
Date: Wed, 25 Aug 2021 14:11:23 +0200	[thread overview]
Message-ID: <175e0e1e-90cd-5c69-69a3-9f44462679e3@redhat.com> (raw)
In-Reply-To: <20210714123739.16493-2-rppt@kernel.org>

On 14.07.21 14:37, Mike Rapoport wrote:
> 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,
> 

Acked-by: David Hildenbrand <david@redhat.com>

-- 
Thanks,

David / dhildenb


  parent reply	other threads:[~2021-08-25 12:11 UTC|newest]

Thread overview: 18+ 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 ` [PATCH 1/4] mm/page_alloc: always initialize memory map for the holes Mike Rapoport
2021-07-31 16:56   ` Guenter Roeck
2021-07-31 18:30     ` Mike Rapoport
2021-07-31 19:11       ` Guenter Roeck
2021-08-25 12:11   ` David Hildenbrand [this message]
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-07-31 17:13     ` Joe Perches
2021-08-03  7:58     ` Mike Rapoport
2021-08-03 16:19       ` Joe Perches
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=175e0e1e-90cd-5c69-69a3-9f44462679e3@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=monstr@monstr.eu \
    --cc=rppt@kernel.org \
    --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 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.