Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp5180783rwd; Mon, 12 Jun 2023 00:51:16 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4SgaMxoHJiW2TfiEHgA1jwtB11QV79etaiGGJoqyk4eavqScCDiqvN3Uv8Ikbi9NFWlJe+ X-Received: by 2002:aca:1c1a:0:b0:39c:64f4:bc71 with SMTP id c26-20020aca1c1a000000b0039c64f4bc71mr3668811oic.53.1686556276611; Mon, 12 Jun 2023 00:51:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686556276; cv=none; d=google.com; s=arc-20160816; b=P02iY7o0uoas1jrt9I4QCTKHD41cQbF6n9rys5gq6GMZdcktfmB88Eg6llFHHLC4Dd EhBDUs8hGK+QL4WK3jzcRUeZ+44UMQap2epiFch2ingkoEBBUaRyh6Bf1+VkOIAvFEdh kFo+ojVdp4de4kJUkxPhLJ+LcOLaInp7R503+fJMVinIr8gDQ5RcwAssF/HHHV6ht1e9 Qd6ugLVgWBT7LK1cVU9o/i+QZ2SfDVtmHbsUoq6F0AFqaxVqng2btSuedTqPypyBWYIR jjzGs2zQthI4cDvh1FyGUPl9ImvVI4MbAXlrG5DG8HcsVNHcncdjOxfqW5oWsL9Adaoj dE4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=wQ71bt9b3FYUgSPlOf8FiPxADV6UnEaiTW42jFRDtmk=; b=uUWUnQxQallgPAP5o2o7ymeRctfJxaXMaImXhZjW3s6DD/1dwc8offtccOL/Racm71 su3qy1CDX39edHBijCEYBloNpxl2ilAKmnMTnHF+7NrendD2mdpctFcr8sIL1pNNo1DS R+q24/gY32qS9M3nZQiFhYjwY3m86Rl5Ni03n1+2SVbnKh8FgtkQu8zd2nzk6HPSvDOW Me+izd93eA/Wm1usVVGKfsqNbS6qKNVBToBoV5UO954qE1T8yQuVsCvWIKYUB371wPsC Cy0wgDohc1e6wTl2Jl6r9GCvFh8r/rGSqmIvW/TRoIHldBF6KRp7CphYTReNv0DAJGfJ H8VA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rivosinc-com.20221208.gappssmtp.com header.s=20221208 header.b=P722nCia; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b5-20020a63eb45000000b0053b8c98d14bsi2963068pgk.859.2023.06.12.00.51.04; Mon, 12 Jun 2023 00:51:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@rivosinc-com.20221208.gappssmtp.com header.s=20221208 header.b=P722nCia; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235018AbjFLHoN (ORCPT + 99 others); Mon, 12 Jun 2023 03:44:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52680 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235271AbjFLHoI (ORCPT ); Mon, 12 Jun 2023 03:44:08 -0400 Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2331C199B for ; Mon, 12 Jun 2023 00:43:35 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2b227fdda27so29269801fa.1 for ; Mon, 12 Jun 2023 00:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20221208.gappssmtp.com; s=20221208; t=1686555742; x=1689147742; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=wQ71bt9b3FYUgSPlOf8FiPxADV6UnEaiTW42jFRDtmk=; b=P722nCiaq2yIdg/3iiugSvm9is7X0mEyUj3q4fADu2UGqsPP1ozMs/8BBqloMTM71+ V4yxp5rLchwYfC6TETyyIEKsS+yGBv2M+WfdensYdpqkJPcX3zPeE5VoXujeh8q0aovJ lzRkgNQAWxiFrlsEpWLd8fCH5/sJw6vOIw48MisYrEhyjqnf5bW3crdrG+0qUa5OBROw 7PnNZyqSqNu/a9YjoynTVlEt8oKsj1ZNFXeXAVAcw8+rVeDnFfjoWep8m9EpuviTvHbt 93/6iKJMTHH+wgDWp+tlL7IldkISFcv6923dTJjf2litTAOtdWkZMYlACaK0MzSjdxPX Y9eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686555742; x=1689147742; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wQ71bt9b3FYUgSPlOf8FiPxADV6UnEaiTW42jFRDtmk=; b=QIxQWMe6fLKOTmA8vwWZTUh6Het5Pf407vPRHRT/Xac2yEoztsNftcQzeEtKERAGJ6 8s3YBb3o4EQ3T43W5oIeKk0Tb48Ks0mLOygjku0H4UHyfDnoFKSVk5wTREFQVLieOSQE CzNXZ0duQpenBGkzKRVyarlX9naF7QFsxs6ws25KPUAOPDWBGeEIjMMt5FxYW4vcJpa9 LTgZ0KBy7YNj7mTNI6GykFhj1+McNZLLuOQofUusEjbIuqyV+i6qWbXfZUtPoAQCA6oP IPai0TOJMG1mvgyFwo44+PVB0g6PVKLPUKaTJemw5DCuAR0Uti5a19+yrmTQCB5OZGtm ZNSw== X-Gm-Message-State: AC+VfDzM86JfXq/TekmLrndnlJ0J4qmr/UeR0PRyFf7c1OZlmtnUOf+y rIgMUgF01ehY4kcufju4n6DP8Sx6vIJ401R4oeN0r3NwPhjXsIR1h7Q= X-Received: by 2002:adf:e403:0:b0:30a:ea65:6676 with SMTP id g3-20020adfe403000000b0030aea656676mr4578723wrm.23.1686554148766; Mon, 12 Jun 2023 00:15:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alexandre Ghiti Date: Mon, 12 Jun 2023 09:15:38 +0200 Message-ID: Subject: Re: [PATCH] riscv: move memblock_allow_resize() after lm is ready To: Woody Zhang Cc: Paul Walmsley , Palmer Dabbelt , Albert Ou , Conor Dooley , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Woody, On Sat, Jun 10, 2023 at 1:49=E2=80=AFAM Woody Zhang = wrote: > > The initial memblock metadata is accessed from kernel image mapping. The > regions arrays need to "reallocated" from memblock and accessed through > linear mapping to cover more memblock regions. So the resizing should > not be allowed until linear mapping is ready. Note that there are > memblock allocations when building linear mapping. > > Signed-off-by: Woody Zhang > --- > arch/riscv/mm/init.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > index 9e9da69720ce..8a33ecbb4d0f 100644 > --- a/arch/riscv/mm/init.c > +++ b/arch/riscv/mm/init.c > @@ -258,7 +258,6 @@ static void __init setup_bootmem(void) > dma_contiguous_reserve(dma32_phys_limit); > if (IS_ENABLED(CONFIG_64BIT)) > hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT); > - memblock_allow_resize(); > } > > #ifdef CONFIG_MMU > @@ -1250,6 +1249,9 @@ static void __init setup_vm_final(void) > csr_write(CSR_SATP, PFN_DOWN(__pa_symbol(swapper_pg_dir)) | satp_= mode); > local_flush_tlb_all(); > > + /* Depend on that Linear Mapping is ready */ > + memblock_allow_resize(); > + > pt_ops_set_late(); > } > #else > -- > 2.39.2 > The commit log does not describe the issue thoroughly enough to me, maybe you could point to the arm64 commit that did the same? I mean commit 24cc61d8cb5a ("arm64: memblock: don't permit memblock resizing until linear mapping is up"). Another point is that I would not put this call into setup_vm_final(), I'd rather add it in paging_init() as it does not seem like a good fit for setup_vm_final(). But that's a nit so up to you of course. Anyway, that's a good catch, thanks! Alex