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: 12057379 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=-16.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 B4458C433DB for ; Sat, 30 Jan 2021 22:10:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 52E6F64E0C for ; Sat, 30 Jan 2021 22:10:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 52E6F64E0C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E9BE66B0006; Sat, 30 Jan 2021 17:10:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E4C8B6B006C; Sat, 30 Jan 2021 17:10:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D64846B006E; Sat, 30 Jan 2021 17:10:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0186.hostedemail.com [216.40.44.186]) by kanga.kvack.org (Postfix) with ESMTP id C20F16B0006 for ; Sat, 30 Jan 2021 17:10:52 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 8C09A3630 for ; Sat, 30 Jan 2021 22:10:52 +0000 (UTC) X-FDA: 77763837144.22.plate55_0917c1a275b4 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id 6A2EA18038E6A for ; Sat, 30 Jan 2021 22:10:52 +0000 (UTC) X-HE-Tag: plate55_0917c1a275b4 X-Filterd-Recvd-Size: 4110 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Sat, 30 Jan 2021 22:10:51 +0000 (UTC) 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_Majcz?= =?utf-8?q?ak?= , 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 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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)); } /*