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=-15.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 E20BCC432BE for ; Tue, 10 Aug 2021 19:21:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6E64D60ED8 for ; Tue, 10 Aug 2021 19:21:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6E64D60ED8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=roeck-us.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id F3FAB6B0072; Tue, 10 Aug 2021 15:21:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EEFE56B0073; Tue, 10 Aug 2021 15:21:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DB81C6B0074; Tue, 10 Aug 2021 15:21:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0189.hostedemail.com [216.40.44.189]) by kanga.kvack.org (Postfix) with ESMTP id BF29F6B0072 for ; Tue, 10 Aug 2021 15:21:52 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 52F281CFAD for ; Tue, 10 Aug 2021 19:21:52 +0000 (UTC) X-FDA: 78460140864.18.FE8F50C Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) by imf15.hostedemail.com (Postfix) with ESMTP id ECC20D006308 for ; Tue, 10 Aug 2021 19:21:51 +0000 (UTC) Received: by mail-oi1-f176.google.com with SMTP id u25so650188oiv.5 for ; Tue, 10 Aug 2021 12:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KAarKHT0m3MJ2O9D6qLLI1k9iEOlT/tM9BSCUbuRaoM=; b=Tz8cUBsx8ilYPTAqokUk3hy5ggYRuO8tc9Poy5urwAq0JoCBrzpxBYXSoEbKNUGFN5 LJHV7Y/Rfuuw2pMsiwoNt2CgjP5JG6SUmW4JT1oBcQLnFglpNdXmRZXFOC2TaFSSpzjv xoPMLiVw6FgJbdcjqpFPvHgUgNcwTRSMaW0NENjzrP7yTjFu83k0kTdjC7xFiL5cbPed NRMD14yFkha2+DR1Wkkqk/YmaAjJklYTeCdTavWo2Fb6kZr1HA7slrPG/6n8FENo0TNn udeRFqfaSXzwL+15UlKeMxfUHCSioFu7eflrwGwB/h5wWwsOEtIwrZyThVK4Q6VlMzAn tKUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KAarKHT0m3MJ2O9D6qLLI1k9iEOlT/tM9BSCUbuRaoM=; b=XFcx0BdNeP5rzd7hI608Y6ZsaThvZGIczinozvKi/SfhSe0RaIbTpQcK/t0LxZqOgl qtSrCGsLSCZIq+gtBxiUJWBvDfEbv2DeofOcnaVelRU6z4Y2lmapotCYySna5x056E2V B57CMtzCa1UBC0hbSANd8EYQKxkoDrYkE8Rluo9f9yDu64mOy74iGUibSblsIVHQi4Zr /ZKL1ffhXNfIFLBGTXQ+o8p9auR1UMLjxYG/KEAb7CiIsIUcODL7F9im0saxdbfxAIbS 6tZsm8yopGtdWGKNj1aL1EFuHCbDxGakEIHClf87j5YGXDiO8cF8yE/SVpq5VE6bZPnr 4E0g== X-Gm-Message-State: AOAM5312YnqXbdd8/VfgEFZ64B4EjsTfH9Vtc6FHWcZYQMy7BbCWwmzA igxmikNuHwiHH7dtDntd/uM= X-Google-Smtp-Source: ABdhPJwKep9KddVoYjOL1882ESwbTAv/JqcCb93BOr2zZaD0Lh8+HcI4C99dC3rYzVoJQsss4q7qLA== X-Received: by 2002:aca:1b11:: with SMTP id b17mr4836676oib.158.1628623311215; Tue, 10 Aug 2021 12:21:51 -0700 (PDT) Received: from server.roeck-us.net ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id j2sm1009805oia.21.2021.08.10.12.21.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Aug 2021 12:21:50 -0700 (PDT) Subject: Re: [PATCH v3] memblock: make memblock_find_in_range method private To: Mike Rapoport Cc: Andrew Morton , Peter Zijlstra , Catalin Marinas , Dave Hansen , linux-mips@vger.kernel.org, linux-mm@kvack.org, Will Deacon , "H. Peter Anvin" , linux-riscv@lists.infradead.org, Frank Rowand , kvmarm@lists.cs.columbia.edu, linux-s390@vger.kernel.org, linux-acpi@vger.kernel.org, Marc Zyngier , x86@kernel.org, Russell King , Mike Rapoport , Christian Borntraeger , Ingo Molnar , Len Brown , devicetree@vger.kernel.org, Albert Ou , Vasily Gorbik , Heiko Carstens , Rob Herring , Borislav Petkov , Andy Lutomirski , Paul Walmsley , "Kirill A. Shutemov" , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Thomas Bogendoerfer , Greg Kroah-Hartman , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, Palmer Dabbelt References: <20210803064218.6611-1-rppt@kernel.org> <20210809190641.GA1176508@roeck-us.net> From: Guenter Roeck Message-ID: <7db20940-cbd9-e900-db28-774c5782601c@roeck-us.net> Date: Tue, 10 Aug 2021 12:21:46 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: ECC20D006308 Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=Tz8cUBsx; dmarc=none; spf=pass (imf15.hostedemail.com: domain of groeck7@gmail.com designates 209.85.167.176 as permitted sender) smtp.mailfrom=groeck7@gmail.com X-Stat-Signature: hjcprbfn6opgrijimoz4aaq43u5gnnxy X-HE-Tag: 1628623311-43151 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: On 8/10/21 11:55 AM, Mike Rapoport wrote: > On Mon, Aug 09, 2021 at 12:06:41PM -0700, Guenter Roeck wrote: >> On Tue, Aug 03, 2021 at 09:42:18AM +0300, Mike Rapoport wrote: >>> From: Mike Rapoport >>> >>> There are a lot of uses of memblock_find_in_range() along with >>> memblock_reserve() from the times memblock allocation APIs did not exist. >>> >>> memblock_find_in_range() is the very core of memblock allocations, so any >>> future changes to its internal behaviour would mandate updates of all the >>> users outside memblock. >>> >>> Replace the calls to memblock_find_in_range() with an equivalent calls to >>> memblock_phys_alloc() and memblock_phys_alloc_range() and make >>> memblock_find_in_range() private method of memblock. >>> >>> This simplifies the callers, ensures that (unlikely) errors in >>> memblock_reserve() are handled and improves maintainability of >>> memblock_find_in_range(). >>> >>> Signed-off-by: Mike Rapoport >> >> I see a number of crashes in next-20210806 when booting x86 images from efi. >> >> [ 0.000000] efi: EFI v2.70 by EDK II >> [ 0.000000] efi: SMBIOS=0x1fbcc000 ACPI=0x1fbfa000 ACPI 2.0=0x1fbfa014 MEMATTR=0x1f25f018 >> [ 0.000000] SMBIOS 2.8 present. >> [ 0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 >> [ 0.000000] last_pfn = 0x1ff50 max_arch_pfn = 0x400000000 >> [ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT >> [ 0.000000] Kernel panic - not syncing: alloc_low_pages: can not alloc memory >> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.14.0-rc4-next-20210806 #1 >> [ 0.000000] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 >> [ 0.000000] Call Trace: >> [ 0.000000] ? dump_stack_lvl+0x57/0x7d >> [ 0.000000] ? panic+0xfc/0x2c6 >> [ 0.000000] ? alloc_low_pages+0x117/0x156 >> [ 0.000000] ? phys_pmd_init+0x234/0x342 >> [ 0.000000] ? phys_pud_init+0x171/0x337 >> [ 0.000000] ? __kernel_physical_mapping_init+0xec/0x276 >> [ 0.000000] ? init_memory_mapping+0x1ea/0x2aa >> [ 0.000000] ? init_range_memory_mapping+0xdf/0x12e >> [ 0.000000] ? init_mem_mapping+0x1e9/0x26f >> [ 0.000000] ? setup_arch+0x5ff/0xb6d >> [ 0.000000] ? start_kernel+0x71/0x6b4 >> [ 0.000000] ? secondary_startup_64_no_verify+0xc2/0xcb >> >> Bisect points to this patch. Reverting it fixes the problem. Key seems to >> be the amount of memory configured in qemu; the problem is not seen if >> there is 1G or more of memory, but it is seen with all test boots with >> 512M or 256M of memory. It is also seen with almost all 32-bit efi boots. >> >> The problem is not seen when booting without efi. > > It looks like this change uncovered a problem in > x86::memory_map_top_down(). > > The allocation in alloc_low_pages() is limited by min_pfn_mapped and > max_pfn_mapped. The min_pfn_mapped is updated at every iteration of the > loop in memory_map_top_down, but there is another loop in > init_range_memory_mapping() that maps several regions below the current > min_pfn_mapped without updating this variable. > > The memory layout in qemu with 256M of RAM and EFI enabled, causes > exhaustion of the memory limited by min_pfn_mapped and max_pfn_mapped > before min_pfn_mapped is updated. > > Before this commit there was unconditional "reservation" of 2M in the end > of the memory that moved the initial min_pfn_mapped below the memory > reserved by EFI. The addition of check for xen_domain() removed this > reservation for !XEN and made alloc_low_pages() use the range already busy > with EFI data. > > The patch below moves the update of min_pfn_mapped near the update of > max_pfn_mapped so that every time a new range is mapped both limits will be > updated accordingly. > > diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c > index 1152a29ce109..be279f6e5a0a 100644 > --- a/arch/x86/mm/init.c > +++ b/arch/x86/mm/init.c > @@ -1,3 +1,4 @@ > +#define DEBUG > #include > #include > #include > @@ -485,6 +486,7 @@ static void add_pfn_range_mapped(unsigned long start_pfn, unsigned long end_pfn) > nr_pfn_mapped = clean_sort_range(pfn_mapped, E820_MAX_ENTRIES); > > max_pfn_mapped = max(max_pfn_mapped, end_pfn); > + min_pfn_mapped = min(min_pfn_mapped, start_pfn); > > if (start_pfn < (1UL<<(32-PAGE_SHIFT))) > max_low_pfn_mapped = max(max_low_pfn_mapped, > @@ -643,7 +645,6 @@ static void __init memory_map_top_down(unsigned long map_start, > mapped_ram_size += init_range_memory_mapping(start, > last_start); > last_start = start; > - min_pfn_mapped = last_start >> PAGE_SHIFT; > if (mapped_ram_size >= step_size) > step_size = get_new_step_size(step_size); > } > The offending patch was removed from next-20210810, but I applied the above change to next-20210809 and it does indeed fix the problem. If it is added as separate patch, please feel free to add Tested-by: Guenter Roeck Thanks, Guenter