All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Mike Rapoport <rppt@kernel.org>
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>, Qian Cai <cai@lca.pw>,
	Vlastimil Babka <vbabka@suse.cz>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	stable@vger.kernel.org
Subject: Re: [PATCH v2 2/2] mm: fix initialization of struct page for holes in memory layout
Date: Thu, 10 Dec 2020 10:29:09 +0100	[thread overview]
Message-ID: <X9HqZZsCalKVMkix@kroah.com> (raw)
In-Reply-To: <20201209214304.6812-3-rppt@kernel.org>

On Wed, Dec 09, 2020 at 11:43:04PM +0200, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
> 
> There could be struct pages that are not backed by actual physical memory.
> This can happen when the actual memory bank is not a multiple of
> SECTION_SIZE or when an architecture does not register memory holes
> reserved by the firmware as memblock.memory.
> 
> Such pages are currently initialized using init_unavailable_mem() function
> that iterated through PFNs in holes in memblock.memory and if there is a
> struct page corresponding to a PFN, the fields if this page are set to
> default values and it is marked as Reserved.
> 
> init_unavailable_mem() does not take into account zone and node the page
> belongs to and sets both zone and node links in struct page to zero.
> 
> On a system that has firmware reserved holes in a zone above ZONE_DMA, for
> instance in a configuration below:
> 
> 	# grep -A1 E820 /proc/iomem
> 	7a17b000-7a216fff : Unknown E820 type
> 	7a217000-7bffffff : System RAM
> 
> unset zone link in struct page will trigger
> 
> 	VM_BUG_ON_PAGE(!zone_spans_pfn(page_zone(page), pfn), page);
> 
> because there are pages in both ZONE_DMA32 and ZONE_DMA (unset zone link in
> struct page) in the same pageblock.
> 
> 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>
> ---
>  mm/page_alloc.c | 152 +++++++++++++++++++++---------------------------
>  1 file changed, 65 insertions(+), 87 deletions(-)


<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>

  parent reply	other threads:[~2020-12-10  9:28 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 [this message]
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
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=X9HqZZsCalKVMkix@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=cai@lca.pw \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@kernel.org \
    --cc=rppt@kernel.org \
    --cc=rppt@linux.ibm.com \
    --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.