Received: by 2002:a05:7412:31a9:b0:e2:908c:2ebd with SMTP id et41csp2952633rdb; Tue, 12 Sep 2023 18:34:14 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGdiPhsheq0fiJErl0CppFS1/65nSJ1WYVNlzC42ydw1o/7xxMzJrXpFE4QkDrGn+3BjbuV X-Received: by 2002:a05:6a00:1913:b0:68f:b3ed:7d56 with SMTP id y19-20020a056a00191300b0068fb3ed7d56mr1277434pfi.34.1694568854008; Tue, 12 Sep 2023 18:34:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694568853; cv=none; d=google.com; s=arc-20160816; b=rGtlcr/rg5KoebPLbGuSAq4AzsGhwzFIPm11Gvdtz7b1Cl0VkvHZzV34Y90YiP7YLZ oM3dIaou0IDZq8OTqBIQ78uSNWvQg7SgrQC1zrySKOgu48BnuXrqOMjw3Q8aj/CAR1J8 1NlywAgJZfKLm9V7di6/AiqnKWAP9fw62y+I6j8kgFJku+IbdoChD+UD3IyuFn5Qqex1 kyEuqpS/ZRLco42yuhrEJ/dfD+c1NIR9uN61qrmym6EB5QbLvdFM41LKY+3UdMyetcw6 diCXh7bUJjHfwXY+eqii57TJ2eiV0e1uICibO/WSkTGc5ys+LH0IjofcYqZkFMe04C2G lf+Q== 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=F0o5Z/PT1epk96gfJ6XJEx5ULvUwHGU1/0ZJhoJvf6U=; fh=zWjNW843QIL0dwFweqoVDTfy4wHJu+nIxpS4FABgC08=; b=ITsx1+lBLxcRRqh5cnWVhlkDV8UntwgtRtMzBcrpmNDuZHbjn0SWowBqGOAus00pB4 Yvz8b0bPXYhPJm05rSFG7dsChs3V91tbxSwNbDAbL4KYbGJezEopyIMEXRmABUChKzEv 6LuwNfuAVX7Jd+2F41UYqpSZhUypNSJwcqiADJCcxXKNB7Cpt5WXWJjfEW4uyxk21P72 ze0NVfHt0v4qG67V8XRBgsOAG3HxVDnlnaZ9Irb2Mibhz0bUoAAnywBBRE6acI+mcgds BYN6W5XvppUTfLkQSoZvaX4gZZRn/scg6O/Com+x8DhApI3laFeR903KrF9RH5vaq0Z9 Jn+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=UlyvFtNl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id n31-20020a63591f000000b0055c77028579si8724477pgb.747.2023.09.12.18.34.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Sep 2023 18:34:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=UlyvFtNl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 515DD80774B5; Tue, 12 Sep 2023 18:34:09 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236790AbjIMBeI (ORCPT + 99 others); Tue, 12 Sep 2023 21:34:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42680 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230113AbjIMBeH (ORCPT ); Tue, 12 Sep 2023 21:34:07 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9484210F6 for ; Tue, 12 Sep 2023 18:34:03 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 297C5C433CA for ; Wed, 13 Sep 2023 01:34:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1694568843; bh=1cOduB5NzSAFGxdYlZ9mahDJ+zC1TtAF7RTbwxcPz4M=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=UlyvFtNlpxRaQjmL1KQi1Em1880aU2p17ODm9mHMtKXHSg77yoaRNUMxQ3egDP38Y IWq+faLpDhlQt35WbyXJFfKIs8d46sYpo9uk0xvGc7m1cZ8EufHjKZwcUuJYQY7n6P FNRP1iy/K3fwPlmvsiQdZ9CmcY3/Z0w5FoirSjK89ukIOJFvJTbH6NYxi9qMikprfJ gxTzkeF5s/PVsBu96kaK24kBgymeUk+5friohyZZUm1OpuTOUqhVQxxiTOn0MPb7Wa SnMIqUrkAoq4ytxvGDmlK9t7/QrD+V0cjjD5inVJrUC1s9OQCXhdJKkgajFeL4q2er xa7+/BTWTqnNQ== Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-9ad8d0be93aso94685866b.0 for ; Tue, 12 Sep 2023 18:34:03 -0700 (PDT) X-Gm-Message-State: AOJu0YyA1iczUY2NIe0CDmZk4SrS5tdedde7PXasNBLLoJx3ABBCBfsF 9nhA+GayTklYHkkXfyb2lK6s1gyHcx4DeOFc0d0= X-Received: by 2002:a17:906:5a42:b0:9a1:b528:d0f6 with SMTP id my2-20020a1709065a4200b009a1b528d0f6mr1515299ejc.27.1694568841506; Tue, 12 Sep 2023 18:34:01 -0700 (PDT) MIME-Version: 1.0 References: <20230911092810.3108092-1-chenhuacai@loongson.cn> In-Reply-To: From: Huacai Chen Date: Wed, 13 Sep 2023 09:33:49 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] LoongArch: Set all reserved memblocks on Node#0 at initialization To: WANG Xuerui Cc: Huacai Chen , loongarch@lists.linux.dev, Xuefeng Li , Guo Ren , Jiaxun Yang , linux-kernel@vger.kernel.org, loongson-kernel@lists.loongnix.cn, WANG Xuerui Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Tue, 12 Sep 2023 18:34:09 -0700 (PDT) X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email On Wed, Sep 13, 2023 at 9:23=E2=80=AFAM WANG Xuerui wro= te: > > On 9/13/23 08:49, Huacai Chen wrote: > > On Wed, Sep 13, 2023 at 12:08=E2=80=AFAM WANG Xuerui wrote: > >> On 9/11/23 17:28, Huacai Chen wrote: > >>> After commit 61167ad5fecdea ("mm: pass nid to reserve_bootmem_region(= )") > >>> we get a panic if DEFERRED_STRUCT_PAGE_INIT is enabled: > >>> > >>> [snip] > >>> > >>> The reason is early memblock_reserve() in memblock_init() set node id > >> Why is it that only "early" but not "late" memblock_reserve() matters?= I > >> failed to see the reason because the arch-specific memblock_init() isn= 't > >> even in the backtrace, which means that *neither* is the culprit. > > Late memblock_reserve() operates on subregions of memblock.memory > > regions. These reserved regions will be set to the correct node at the > > first iteration of memmap_init_reserved_pages(). > Thanks for the clarification. According to the code behavior (and the > comment I left on the reordering change below) I'm now sure the intended > meaning is "calling memblock_reserve() after memblock_set_node() is > effectively leaving those regions with nid=3DMAX_NUMNODES" (or something > like that, pointing out that the memblock_set_node() call actually had > no effect in this case). "Early" and "late" in the context of init code > can be especially confusing IMO :-) The "early call" specifically means these lines: /* Reserve the first 2MB */ memblock_reserve(PHYS_OFFSET, 0x200000); /* Reserve the kernel text/data/bss */ memblock_reserve(__pa_symbol(&_text), __pa_symbol(&_end) - __pa_symbol(&_text)); These two regions can be out of initial memory maps. Other later memblock_reserve() regions must be in initial memory maps, so will get a correct node id. Huacai > > > > Huacai > > > >>> to MAX_NUMNODES, which causes NODE_DATA(nid) be a NULL dereference in > >> "making NODE_DATA(nid) a NULL ..." > >>> reserve_bootmem_region() -> init_reserved_page(). So set all reserved > >>> memblocks on Node#0 at initialization to avoid this panic. > >>> > >>> Reported-by: WANG Xuerui > >>> Signed-off-by: Huacai Chen > >>> --- > >>> arch/loongarch/kernel/mem.c | 4 +++- > >>> 1 file changed, 3 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/arch/loongarch/kernel/mem.c b/arch/loongarch/kernel/mem.= c > >>> index 4a4107a6a965..aed901c57fb4 100644 > >>> --- a/arch/loongarch/kernel/mem.c > >>> +++ b/arch/loongarch/kernel/mem.c > >>> @@ -50,7 +50,6 @@ void __init memblock_init(void) > >>> } > >>> > >>> memblock_set_current_limit(PFN_PHYS(max_low_pfn)); > >>> - memblock_set_node(0, PHYS_ADDR_MAX, &memblock.memory, 0); > >>> > >>> /* Reserve the first 2MB */ > >>> memblock_reserve(PHYS_OFFSET, 0x200000); > >>> @@ -58,4 +57,7 @@ void __init memblock_init(void) > >>> /* Reserve the kernel text/data/bss */ > >>> memblock_reserve(__pa_symbol(&_text), > >>> __pa_symbol(&_end) - __pa_symbol(&_text)); > >>> + > >>> + memblock_set_node(0, PHYS_ADDR_MAX, &memblock.memory, 0); > >>> + memblock_set_node(0, PHYS_ADDR_MAX, &memblock.reserved, 0); > >> So the reordering is for being able to override the newly added > >> memblocks' nids to 0, and additionally doing the same for > >> memblock.reserved is the actual fix. Looks okay. > >>> } > >> And I've tested the patch on the 2-way 3C5000L server, and it now > >> correctly boots with deferred struct page init enabled. Thanks for > >> providing such a quick fix! > >> > >> Tested-by: WANG Xuerui > >> Reviewed-by: WANG Xuerui # with nits addressed > >> > >> -- > >> WANG "xen0n" Xuerui > >> > >> Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/ > >> > >> > -- > WANG "xen0n" Xuerui > > Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/ >