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=-16.0 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 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 E488BC4361B for ; Sun, 20 Dec 2020 06:51:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A8C1022D37 for ; Sun, 20 Dec 2020 06:51:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727249AbgLTGut (ORCPT ); Sun, 20 Dec 2020 01:50:49 -0500 Received: from mail.kernel.org ([198.145.29.99]:49928 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726902AbgLTGut (ORCPT ); Sun, 20 Dec 2020 01:50:49 -0500 Date: Sun, 20 Dec 2020 08:49:59 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1608447008; bh=ghtVpco/CElLWsQp/DGYBYzdKOq7lWqU2pYzlTbcGzI=; h=From:To:Cc:Subject:References:In-Reply-To:From; b=OsUoP4Lrx9V2VcPtw93YbBNTR3dKQjIAAm1nTiS2KXOXo0FOE9VAUjUuRvUI/vXzu ZL9JhYILwWybwYmDX/Q8xGql/vaH0AvAOLnv5OpoMyfjUrzZ0pRbb2B6cBeJLQ2tW3 xgi/eLDlK8trriUPlfRV9tcuuzDBr3NP+mAhYU0e5T4EzdMaDgahiW+C1hySweEXDG k/5bCPBZ7T3cbrZoj2ExTjsmProval0HEgM1HM/GcmTYrjCeBrbvmw5eFnw8o7xsFy FrpkOk4e+j+CsXCTAV8RWTHoAAXX3aDuvjeS1Kh6Bc4UJ5nL5BZh9NWxMah6M/5xrX 3ebPidsknTeQw== From: Mike Rapoport To: Roman Gushchin Cc: Andrew Morton , linux-mm@kvack.org, Joonsoo Kim , Rik van Riel , Michal Hocko , linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH v2 2/2] memblock: do not start bottom-up allocations with kernel_end Message-ID: <20201220064959.GB392325@kernel.org> References: <20201217201214.3414100-1-guro@fb.com> <20201217201214.3414100-2-guro@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201217201214.3414100-2-guro@fb.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 17, 2020 at 12:12:14PM -0800, Roman Gushchin wrote: > With kaslr the kernel image is placed at a random place, so starting > the bottom-up allocation with the kernel_end can result in an > allocation failure and a warning like this one: > > [ 0.002920] hugetlb_cma: reserve 2048 MiB, up to 2048 MiB per node > [ 0.002921] ------------[ cut here ]------------ > [ 0.002922] memblock: bottom-up allocation failed, memory hotremove may be affected > [ 0.002937] WARNING: CPU: 0 PID: 0 at mm/memblock.c:332 memblock_find_in_range_node+0x178/0x25a > [ 0.002937] Modules linked in: > [ 0.002939] CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0+ #1169 > [ 0.002940] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 > [ 0.002942] RIP: 0010:memblock_find_in_range_node+0x178/0x25a > [ 0.002944] Code: e9 6d ff ff ff 48 85 c0 0f 85 da 00 00 00 80 3d 9b 35 df 00 00 75 15 48 c7 c7 c0 75 59 88 c6 05 8b 35 df 00 01 e8 25 8a fa ff <0f> 0b 48 c7 44 24 20 ff ff ff ff 44 89 e6 44 89 ea 48 c7 c1 70 5c > [ 0.002945] RSP: 0000:ffffffff88803d18 EFLAGS: 00010086 ORIG_RAX: 0000000000000000 > [ 0.002947] RAX: 0000000000000000 RBX: 0000000240000000 RCX: 00000000ffffdfff > [ 0.002948] RDX: 00000000ffffdfff RSI: 00000000ffffffea RDI: 0000000000000046 > [ 0.002948] RBP: 0000000100000000 R08: ffffffff88922788 R09: 0000000000009ffb > [ 0.002949] R10: 00000000ffffe000 R11: 3fffffffffffffff R12: 0000000000000000 > [ 0.002950] R13: 0000000000000000 R14: 0000000080000000 R15: 00000001fb42c000 > [ 0.002952] FS: 0000000000000000(0000) GS:ffffffff88f71000(0000) knlGS:0000000000000000 > [ 0.002953] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 0.002954] CR2: ffffa080fb401000 CR3: 00000001fa80a000 CR4: 00000000000406b0 > [ 0.002956] Call Trace: > [ 0.002961] ? memblock_alloc_range_nid+0x8d/0x11e > [ 0.002963] ? cma_declare_contiguous_nid+0x2c4/0x38c > [ 0.002964] ? hugetlb_cma_reserve+0xdc/0x128 > [ 0.002968] ? flush_tlb_one_kernel+0xc/0x20 > [ 0.002969] ? native_set_fixmap+0x82/0xd0 > [ 0.002971] ? flat_get_apic_id+0x5/0x10 > [ 0.002973] ? register_lapic_address+0x8e/0x97 > [ 0.002975] ? setup_arch+0x8a5/0xc3f > [ 0.002978] ? start_kernel+0x66/0x547 > [ 0.002980] ? load_ucode_bsp+0x4c/0xcd > [ 0.002982] ? secondary_startup_64_no_verify+0xb0/0xbb > [ 0.002986] random: get_random_bytes called from __warn+0xab/0x110 with crng_init=0 > [ 0.002988] ---[ end trace f151227d0b39be70 ]--- > > At the same time, the kernel image is protected with memblock_reserve(), > so we can just start searching at PAGE_SIZE. In this case the > bottom-up allocation has the same chances to success as a top-down > allocation, so there is no reason to fallback in the case of a > failure. All together it simplifies the logic. > > Signed-off-by: Roman Gushchin Reviewed-by: Mike Rapoport > --- > mm/memblock.c | 49 ++++++------------------------------------------- > 1 file changed, 6 insertions(+), 43 deletions(-) > > diff --git a/mm/memblock.c b/mm/memblock.c > index b68ee86788af..10bd7d1ef0f4 100644 > --- a/mm/memblock.c > +++ b/mm/memblock.c > @@ -275,14 +275,6 @@ __memblock_find_range_top_down(phys_addr_t start, phys_addr_t end, > * > * Find @size free area aligned to @align in the specified range and node. > * > - * When allocation direction is bottom-up, the @start should be greater > - * than the end of the kernel image. Otherwise, it will be trimmed. The > - * reason is that we want the bottom-up allocation just near the kernel > - * image so it is highly likely that the allocated memory and the kernel > - * will reside in the same node. > - * > - * If bottom-up allocation failed, will try to allocate memory top-down. > - * > * Return: > * Found address on success, 0 on failure. > */ > @@ -291,8 +283,6 @@ static phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t size, > phys_addr_t end, int nid, > enum memblock_flags flags) > { > - phys_addr_t kernel_end, ret; > - > /* pump up @end */ > if (end == MEMBLOCK_ALLOC_ACCESSIBLE || > end == MEMBLOCK_ALLOC_KASAN) > @@ -301,40 +291,13 @@ static phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t size, > /* avoid allocating the first page */ > start = max_t(phys_addr_t, start, PAGE_SIZE); > end = max(start, end); > - kernel_end = __pa_symbol(_end); > - > - /* > - * try bottom-up allocation only when bottom-up mode > - * is set and @end is above the kernel image. > - */ > - if (memblock_bottom_up() && end > kernel_end) { > - phys_addr_t bottom_up_start; > - > - /* make sure we will allocate above the kernel */ > - bottom_up_start = max(start, kernel_end); > > - /* ok, try bottom-up allocation first */ > - ret = __memblock_find_range_bottom_up(bottom_up_start, end, > - size, align, nid, flags); > - if (ret) > - return ret; > - > - /* > - * we always limit bottom-up allocation above the kernel, > - * but top-down allocation doesn't have the limit, so > - * retrying top-down allocation may succeed when bottom-up > - * allocation failed. > - * > - * bottom-up allocation is expected to be fail very rarely, > - * so we use WARN_ONCE() here to see the stack trace if > - * fail happens. > - */ > - WARN_ONCE(IS_ENABLED(CONFIG_MEMORY_HOTREMOVE), > - "memblock: bottom-up allocation failed, memory hotremove may be affected\n"); > - } > - > - return __memblock_find_range_top_down(start, end, size, align, nid, > - flags); > + if (memblock_bottom_up()) > + return __memblock_find_range_bottom_up(start, end, size, align, > + nid, flags); > + else > + return __memblock_find_range_top_down(start, end, size, align, > + nid, flags); > } > > /** > -- > 2.26.2 > -- Sincerely yours, Mike.