From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 129D5C433DB for ; Sat, 30 Jan 2021 22:11:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DD0DC61492 for ; Sat, 30 Jan 2021 22:11:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232274AbhA3WLa (ORCPT ); Sat, 30 Jan 2021 17:11:30 -0500 Received: from mail.kernel.org ([198.145.29.99]:57704 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230168AbhA3WL0 (ORCPT ); Sat, 30 Jan 2021 17:11:26 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id C154561492; Sat, 30 Jan 2021 22:10:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1612044645; bh=77YcxH+eCPwOFkQU6sZz0QWeMg6cwRdjlKD7GsMTqwU=; h=From:To:Cc:Subject:Date:From; b=iDaX/syaAW2XrojjStjvRMKYtZEIRJgVm71qjEFEjf+FqsqaAT0btQKSTi2eaB9mM nu+J+UhagiBUICloKRUDvnj0MtJ5G8uFg8g2o0e+n8k7qEXiDKfDMIeMWlc1fSzIpw a4AvQ2POs2C+tgLjyp+Wg2BtlCoxpumaKIUMYv6o0MUgf29HJkinzONA0rOa34KpS3 0xo7x+9fgH6iAjBGcEb3rRkm02hlChI5rkh1rdGDIG60DeIssdPB+n1HHg2Pd2AbVv DfadvqxXZ09Qt+Q7cm3NQdvOCbFaOVH0ifYTglX4FhQDuenq3F7mQc43oP25nho5z/ h4RLvojt2uqfw== From: Mike Rapoport To: Andrew Morton Cc: Andrea Arcangeli , Baoquan He , Borislav Petkov , Chris Wilson , David Hildenbrand , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , =?UTF-8?q?=C5=81ukasz=20Majczak?= , Mel Gorman , Michal Hocko , Mike Rapoport , Mike Rapoport , Qian Cai , "Sarvela, Tomi P" , Thomas Gleixner , Vlastimil Babka , linux-kernel@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org, x86@kernel.org Subject: [PATCH v4 0/2] mm: fix initialization of struct page for holes in memory layout Date: Sun, 31 Jan 2021 00:10:33 +0200 Message-Id: <20210130221035.4169-1-rppt@kernel.org> X-Mailer: git-send-email 2.28.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Mike Rapoport Hi, Commit 73a6e474cb37 ("mm: memmap_init: iterate over memblock regions rather that check each PFN") exposed several issues with the memory map initialization and these patches fix those issues. Initially there were crashes during compaction that Qian Cai reported back in April [1]. It seemed back then that the problem was fixed, but a few weeks ago Andrea Arcangeli hit the same bug [2] and there was an additional discussion at [3]. I didn't appreciate variety of ways BIOSes can report memory in the first megabyte, so v3 of this set caused boot failures on several x86 systems. Hopefully this time I covered all the bases. The first patch here complements commit bde9cfa3afe4 ("x86/setup: don't remove E820_TYPE_RAM for pfn 0") for the cases when BIOS reports the first page as absent or reserved. The second patch is a more robust version of d3921cb8be29 ("mm: fix initialization of struct page for holes in memory layout") that can now handle the above cases as well. v4: * make sure pages in the range 0 - start_pfn_of_lowest_zone are initialized even if an architecture hides them from the generic mm * finally make pfn 0 on x86 to be a part of memory visible to the generic mm as reserved memory. v3: https://lore.kernel.org/lkml/20210111194017.22696-1-rppt@kernel.org * use architectural zone constraints to set zone links for struct pages corresponding to the holes * drop implicit update of memblock.memory * add a patch that sets pfn 0 to E820_TYPE_RAM on x86 v2: https://lore.kernel.org/lkml/20201209214304.6812-1-rppt@kernel.org/): * added patch that adds all regions in memblock.reserved that do not overlap with memblock.memory to memblock.memory in the beginning of free_area_init() [1] https://lore.kernel.org/lkml/8C537EB7-85EE-4DCF-943E-3CC0ED0DF56D@lca.pw [2] https://lore.kernel.org/lkml/20201121194506.13464-1-aarcange@redhat.com [3] https://lore.kernel.org/mm-commits/20201206005401.qKuAVgOXr%akpm@linux-foundation.org Mike Rapoport (2): x86/setup: always add the beginning of RAM as memblock.memory mm: fix initialization of struct page for holes in memory layout arch/x86/kernel/setup.c | 8 ++++ mm/page_alloc.c | 85 ++++++++++++++++++++++++----------------- 2 files changed, 59 insertions(+), 34 deletions(-) -- 2.28.0