Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2038823imm; Mon, 16 Jul 2018 00:39:30 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcCnfA74G2feB61ykJXBa5y3NrJgpIFvZiDIwbPMHQCk0E8wHEaEDico3DQQWCTnEqwnGVS X-Received: by 2002:a63:1902:: with SMTP id z2-v6mr14265767pgl.86.1531726770586; Mon, 16 Jul 2018 00:39:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531726770; cv=none; d=google.com; s=arc-20160816; b=fc2klRSHJeXBF241Tfztjikd5JPvRhC4AiQl2jVvTWBTZfZoNFTdmNP19xVreYRCN3 bIM198vsev/w0Gy2w+tpda/7CzPTa3ZmLkl+aETaS7wbiV4iC6qBwZZcIZnRn6629Mcq 3ZgukmR71ATrr8rYlmp5prI9RybKHnnrl3c9DlSYEGjpnut8S0Utu+8hOs6uC+z+g8tM B0frQ1u4NJQGfXhNAa1etTWkK1tO4GNM3V45E3l/t0XQBIGUKLwSLst5JezgvUqFtu0v N8urJfVqA211YjySdn0t1MfXZBibRsjGfTy6EFMZjGySo/NC9s7V2MO5Vw26CocG+3m+ cIXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=XMOg93F2cSjLKUBtvdvICOo357nlNEpPJrLsd2nQlRg=; b=JSe8rjnudbQara6i/i88y+8d7LCwt821rq98LteQssEqILRqyhEGXOczQyp+F6nEyk 95af6brnok5lyqeVYxAgFDuscWuVTzNrMzNwHoFMrCnIrG5G7uOyS8+aXVpZOt4ehC+M shdluwdICHNF9/vClcwvYSSfOGDMStiaARfZrTZWBXu1nxwzz6Zwso7q7jm5QwVRw3tQ KSh5DQFx8jPz3gNgMdJCuY821QGSeOUhRqQjNXYzyw73lgRNu/uZXfOji/RMujNxwzPc cbmHxdKgJ591RXFwowvhyMM7GiNUoxlRHY2R0m16syKCBhaFPxx5LTjUld/tTp2JTIIE TUdQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b2-v6si28918387plx.88.2018.07.16.00.39.15; Mon, 16 Jul 2018 00:39:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732178AbeGPIEW (ORCPT + 99 others); Mon, 16 Jul 2018 04:04:22 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:46892 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729883AbeGPIEV (ORCPT ); Mon, 16 Jul 2018 04:04:21 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 610E5CA1; Mon, 16 Jul 2018 07:38:20 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pavel Tatashin , Linus Torvalds Subject: [PATCH 4.17 32/67] mm: zero unavailable pages before memmap init Date: Mon, 16 Jul 2018 09:35:01 +0200 Message-Id: <20180716073448.234284402@linuxfoundation.org> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180716073443.294323458@linuxfoundation.org> References: <20180716073443.294323458@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.17-stable review patch. If anyone has any objections, please let me know. ------------------ From: Pavel Tatashin commit e181ae0c5db9544de9c53239eb22bc012ce75033 upstream. We must zero struct pages for memory that is not backed by physical memory, or kernel does not have access to. Recently, there was a change which zeroed all memmap for all holes in e820. Unfortunately, it introduced a bug that is discussed here: https://www.spinics.net/lists/linux-mm/msg156764.html Linus, also saw this bug on his machine, and confirmed that reverting commit 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into memblock.reserved") fixes the issue. The problem is that we incorrectly zero some struct pages after they were setup. The fix is to zero unavailable struct pages prior to initializing of struct pages. A more detailed fix should come later that would avoid double zeroing cases: one in __init_single_page(), the other one in zero_resv_unavail(). Fixes: 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into memblock.reserved") Signed-off-by: Pavel Tatashin Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- mm/page_alloc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -6841,6 +6841,7 @@ void __init free_area_init_nodes(unsigne /* Initialise every node */ mminit_verify_pageflags_layout(); setup_nr_node_ids(); + zero_resv_unavail(); for_each_online_node(nid) { pg_data_t *pgdat = NODE_DATA(nid); free_area_init_node(nid, NULL, @@ -6851,7 +6852,6 @@ void __init free_area_init_nodes(unsigne node_set_state(nid, N_MEMORY); check_for_memory(pgdat, nid); } - zero_resv_unavail(); } static int __init cmdline_parse_core(char *p, unsigned long *core, @@ -7027,9 +7027,9 @@ void __init set_dma_reserve(unsigned lon void __init free_area_init(unsigned long *zones_size) { + zero_resv_unavail(); free_area_init_node(0, zones_size, __pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL); - zero_resv_unavail(); } static int page_alloc_cpu_dead(unsigned int cpu)