From patchwork Sat Jan 30 22:10:34 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mike Rapoport X-Patchwork-Id: 374204 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=-19.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=ham 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 2DCEDC433DB for ; Sat, 30 Jan 2021 22:11:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EB5D964DE2 for ; Sat, 30 Jan 2021 22:11:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232290AbhA3WLg (ORCPT ); Sat, 30 Jan 2021 17:11:36 -0500 Received: from mail.kernel.org ([198.145.29.99]:57772 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230168AbhA3WLb (ORCPT ); Sat, 30 Jan 2021 17:11:31 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id ABFC764E13; Sat, 30 Jan 2021 22:10:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1612044651; bh=NwGBqLKT4lv56fTEcCR2ndp0EzU/2WJrIaR7bVOuDq4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tYLXvtrD8alXfHilnW1A5oTqydktopfoSZwHOS/QQOtED+KBZs1Z4I7MOL76yYe8s 6+CwAGpI0JrW0/OlZiYuELzreA0SC5h4cD7i7Np7kCuvLU0oAKFY0o4Lw60DYTjnKW N45agfUnpbuLNPpTPE5V32wNZF+GlF04S/NT/zC/NmYZaA/BjLQFFlX1opyi6rX5wh rDYj8xd63/Ud1rgDL3atULvLHGnCu7Qg9NkR2BxLecey5T7/jP6+LzdKuI8gBCKFAl 9kukhwBWOhdrDmuYxmvRjcLE9/9boF1GFllpfX6wJdC2PgBtHeF44sfWDoYpmGWfel +OYGPt9m96CFg== 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_Majczak?= , 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 1/2] x86/setup: always add the beginning of RAM as memblock.memory Date: Sun, 31 Jan 2021 00:10:34 +0200 Message-Id: <20210130221035.4169-2-rppt@kernel.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20210130221035.4169-1-rppt@kernel.org> References: <20210130221035.4169-1-rppt@kernel.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Mike Rapoport The physical memory on an x86 system starts at address 0, but this is not always reflected in e820 map. For example, the BIOS can have e820 entries like [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: [mem 0x0000000000001000-0x000000000009ffff] usable or [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000001000-0x0000000000057fff] usable In either case, e820__memblock_setup() won't add the range 0x0000 - 0x1000 to memblock.memory and later during memory map initialization this range is left outside any zone. With SPARSEMEM=y there is always a struct page for pfn 0 and this struct page will have it's zone link wrong no matter what value will be set there. To avoid this inconsistency, add the beginning of RAM to memblock.memory. Limit the added chunk size to match the reserved memory to avoid registering memory that may be used by the firmware but never reserved at e820__memblock_setup() time. Fixes: bde9cfa3afe4 ("x86/setup: don't remove E820_TYPE_RAM for pfn 0") Signed-off-by: Mike Rapoport Cc: stable@vger.kernel.org --- arch/x86/kernel/setup.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 3412c4595efd..67c77ed6eef8 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -727,6 +727,14 @@ static void __init trim_low_memory_range(void) * Kconfig help text for X86_RESERVE_LOW. */ memblock_reserve(0, ALIGN(reserve_low, PAGE_SIZE)); + + /* + * Even if the firmware does not report the memory at address 0 as + * usable, inform the generic memory management about its existence + * to ensure it is a part of ZONE_DMA and the memory map for it is + * properly initialized. + */ + memblock_add(0, ALIGN(reserve_low, PAGE_SIZE)); } /* From patchwork Sat Jan 30 22:10:35 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mike Rapoport X-Patchwork-Id: 374038 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=-19.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, INCLUDES_CR_TRAILER, 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 3849DC433E6 for ; Sat, 30 Jan 2021 22:11:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0BAAE61492 for ; Sat, 30 Jan 2021 22:11:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232295AbhA3WLo (ORCPT ); Sat, 30 Jan 2021 17:11:44 -0500 Received: from mail.kernel.org ([198.145.29.99]:57834 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232294AbhA3WLi (ORCPT ); Sat, 30 Jan 2021 17:11:38 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9812C64E17; Sat, 30 Jan 2021 22:10:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1612044657; bh=uweP3IA5Ah8RvBraXjpUfVIm90iQThv0IPNmBKquaHw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VZwFnTgaxJfbs/DWQjLVIU3MGnMRMdFZbWe0HBLkiTTVYWTdn9nCv5lN+EEjLDlRB SvvRqajh6hv0ah/xoxCzZqAgh0F9ykpx+TsKKqqCtC/4UYQah/xlY4K6JcWEkCwRjv 98KXyimOgTtP1pBrPfZd93cBaLW6kl7uJrpmA6sfft7J1nFkBwb+of+0unOw4vNHGh 8/Hy2Wx/puTbHitPXDSjk5xIffRteWEofVgMg55Gle+OSH0vlu5SdLFv52Qg1moATZ 9UmusQnQARryQEUIbOItsdDz2TcmzlJVIPPq8UO6rBTmXzCTlrMQnw24nkt0KhFbnm MgMaPgKjooDIQ== 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_Majczak?= , 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 2/2] mm: fix initialization of struct page for holes in memory layout Date: Sun, 31 Jan 2021 00:10:35 +0200 Message-Id: <20210130221035.4169-3-rppt@kernel.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20210130221035.4169-1-rppt@kernel.org> References: <20210130221035.4169-1-rppt@kernel.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Mike Rapoport 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 iterates 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 the page 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. Update init_unavailable_mem() to use zone constraints defined by an architecture to properly setup the zone link and use node ID of the adjacent range in memblock.memory to set the node link. Fixes: 73a6e474cb37 ("mm: memmap_init: iterate over memblock regions rather that check each PFN") Signed-off-by: Mike Rapoport Reported-by: Andrea Arcangeli Cc: --- mm/page_alloc.c | 85 +++++++++++++++++++++++++++++-------------------- 1 file changed, 51 insertions(+), 34 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 519a60d5b6f7..444642393bb6 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -7080,23 +7080,27 @@ void __init free_area_init_memoryless_node(int nid) * Initialize all valid struct pages in the range [spfn, epfn) and mark them * PageReserved(). Return the number of struct pages that were initialized. */ -static u64 __init init_unavailable_range(unsigned long spfn, unsigned long epfn) +static u64 __init init_unavailable_range(unsigned long spfn, unsigned long epfn, + int zone, int nid) { - unsigned long pfn; + unsigned long pfn, zone_epfn, zone_spfn = 0; u64 pgcnt = 0; + if (zone) + zone_spfn = arch_zone_highest_possible_pfn[zone - 1]; + zone_epfn = arch_zone_highest_possible_pfn[zone]; + + spfn = clamp(spfn, zone_spfn, zone_epfn); + epfn = clamp(epfn, zone_spfn, zone_epfn); + for (pfn = spfn; pfn < epfn; pfn++) { if (!pfn_valid(ALIGN_DOWN(pfn, pageblock_nr_pages))) { pfn = ALIGN_DOWN(pfn, pageblock_nr_pages) + pageblock_nr_pages - 1; continue; } - /* - * Use a fake node/zone (0) for now. Some of these pages - * (in memblock.reserved but not in memblock.memory) will - * get re-initialized via reserve_bootmem_region() later. - */ - __init_single_page(pfn_to_page(pfn), pfn, 0, 0); + + __init_single_page(pfn_to_page(pfn), pfn, zone, nid); __SetPageReserved(pfn_to_page(pfn)); pgcnt++; } @@ -7105,51 +7109,64 @@ static u64 __init init_unavailable_range(unsigned long spfn, unsigned long epfn) } /* - * Only struct pages that are backed by physical memory are zeroed and - * initialized by going through __init_single_page(). But, there are some - * struct pages which are reserved in memblock allocator and their fields - * may be accessed (for example page_to_pfn() on some configuration accesses - * flags). We must explicitly initialize those struct pages. + * Only struct pages that correspond to ranges defined by memblock.memory + * are zeroed and initialized by going through __init_single_page() during + * memmap_init(). * - * This function also addresses a similar issue where struct pages are left - * uninitialized because the physical address range is not covered by - * memblock.memory or memblock.reserved. That could happen when memblock - * layout is manually configured via memmap=, or when the highest physical - * address (max_pfn) does not end on a section boundary. + * But, there could be struct pages that correspond to holes in + * memblock.memory. This can happen because of the following reasons: + * - phyiscal memory bank size is not necessarily the exact multiple of the + * arbitrary section size + * - early reserved memory may not be listed in memblock.memory + * - memory layouts defined with memmap= kernel parameter may not align + * nicely with memmap sections + * + * Explicitly initialize those struct pages so that: + * - PG_Reserved is set + * - zone link is set accorging to the architecture constrains + * - node is set to node id of the next populated region except for the + * trailing hole where last node id is used */ -static void __init init_unavailable_mem(void) +static void __init init_zone_unavailable_mem(int zone) { - phys_addr_t start, end; - u64 i, pgcnt; - phys_addr_t next = 0; + unsigned long start, end; + int i, nid; + u64 pgcnt; + unsigned long next = 0; /* - * Loop through unavailable ranges not covered by memblock.memory. + * Loop through holes in memblock.memory and initialize struct + * pages corresponding to these holes */ pgcnt = 0; - for_each_mem_range(i, &start, &end) { + for_each_mem_pfn_range(i, MAX_NUMNODES, &start, &end, &nid) { if (next < start) - pgcnt += init_unavailable_range(PFN_DOWN(next), - PFN_UP(start)); + pgcnt += init_unavailable_range(next, start, zone, nid); next = end; } /* - * Early sections always have a fully populated memmap for the whole - * section - see pfn_valid(). If the last section has holes at the - * end and that section is marked "online", the memmap will be - * considered initialized. Make sure that memmap has a well defined - * state. + * Last section may surpass the actual end of memory (e.g. we can + * have 1Gb section and 512Mb of RAM pouplated). + * Make sure that memmap has a well defined state in this case. */ - pgcnt += init_unavailable_range(PFN_DOWN(next), - round_up(max_pfn, PAGES_PER_SECTION)); + end = round_up(max_pfn, PAGES_PER_SECTION); + pgcnt += init_unavailable_range(next, end, zone, nid); /* * Struct pages that do not have backing memory. This could be because * firmware is using some of this memory, or for some other reasons. */ if (pgcnt) - pr_info("Zeroed struct page in unavailable ranges: %lld pages", pgcnt); + pr_info("Zone %s: zeroed struct page in unavailable ranges: %lld pages", zone_names[zone], pgcnt); +} + +static void __init init_unavailable_mem(void) +{ + int zone; + + for (zone = 0; zone < ZONE_MOVABLE; zone++) + init_zone_unavailable_mem(zone); } #else static inline void __init init_unavailable_mem(void)