Received: by 2002:a05:7412:8d09:b0:fa:4c10:6cad with SMTP id bj9csp316578rdb; Tue, 16 Jan 2024 00:40:07 -0800 (PST) X-Google-Smtp-Source: AGHT+IHmvSUsx6/ndfVObufI0aqEgwITLkKcYXcva2t+1e9Ox02Tm083nse5CqqUN/lDvJj69bht X-Received: by 2002:a05:620a:1139:b0:783:6682:e4f8 with SMTP id p25-20020a05620a113900b007836682e4f8mr1839351qkk.76.1705394407413; Tue, 16 Jan 2024 00:40:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1705394407; cv=none; d=google.com; s=arc-20160816; b=JYB7xtY/IXQD5a3vPLXaDXe9gAPmM8oc7y/me+9JAmEaocl4SLVS6/ahaJ62GmRQxa aYruc19p2PyPgLYGsHGCL35E3ZapKhbABA7ZDYBLZsa7PK7zCwWL6lPMZYS5ZEsp3NUw KGlldve/Tpp62Pu/XhaIEWW5nZab0DA8uvKW/lJ2j7Mp4/voCiA4yzXTsdRZ0oluoY0N DT3hZUo5HBiowX1gpuGWWYB5mT4GasVS3xE6EZOoaAYUI9VraLD8+l+MSAFtGSr8zfVA EyTSVtDaBGTX4s4CSXTRPIu3VkVN1wEjoEMQczV1Yxsi09befAo1WE1VDeuUEJ044Aup xpBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:date:dkim-signature; bh=MjD/D9BDOc2zNikcvdOzeLq1I8/Yv/P6iCtAqsKgyqw=; fh=YhuTaNGsaiRbpnvHFOiO+g4EktORyZ1MCiqm4p6DNes=; b=FSlKBJAhuYlF12VvQ97hzqQix1PJpzDySwX45KgiXB7F/K4UZ3TWoyx4jl/I//4PPQ 2fa1eVWr+ChyCC9XyXGKDg5YLV5dH9sHcm0NLNL/5vini2svEIQX9BrVdWpJhEIpLZSG GM3TjcVL+LNgcJnKr0NHpXeEBoQ4gOJ8XCA9U4r13aFS/1BXW78n2+lEJ/urzODq66wu nop6Uh1TuV54KRpiiYSwePQ/RKI2YvnoiGQmRarLhPS2+x0cb4WcQ1Z/IowPhbMbu2DA 6kS6D3MmSMBGQjMWu4lA18CZSeHq2TfLgrTumQ/xTJe8apeGUnpKn8Ql5ojldse55ENu LAAg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=akc4r1LU; spf=pass (google.com: domain of linux-kernel+bounces-27134-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-27134-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id j24-20020a05620a0a5800b0078366fee510si1444148qka.166.2024.01.16.00.40.07 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jan 2024 00:40:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-27134-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=akc4r1LU; spf=pass (google.com: domain of linux-kernel+bounces-27134-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-27134-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 9E5441C22CFF for ; Tue, 16 Jan 2024 08:40:03 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 058A412B66; Tue, 16 Jan 2024 08:39:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="akc4r1LU" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 30748125A3; Tue, 16 Jan 2024 08:39:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AFED1C433F1; Tue, 16 Jan 2024 08:39:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1705394386; bh=zMBkNvcbW1+IjSGQQV5Zw6ssVa4un4ZiyvEjDOZ0/UQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=akc4r1LUSBobkRaqvTAjbmScrg3YVE9bgsGUF/R4Deev/WicJd81uP8RUtACPi+1Y ijs7qcDxLzOAa+xAz7a6M747uoIxAQo5W1buqO6IbRYpNLARGM1LZlKLpCzpaPanoJ HtCh/TOB3AMTxe/irtQDm0KrDJXZGhVCf9X6hsMyQiNY6/4nMdfzHmAGTM9to2Z7Fx tN28jAtzPrfmeKqGxcxuV+Rqc/NBoc4Yb262+SXGE0k7qlzQxm5ZY15dboItZUG56h o9+hrfGKOlQwMVMafr2ueLWjfs1fsjjVFRKsFgLCJKj8lC1tFdXaOcXSzeLm+7qHff o+GRrPnB19CCA== Date: Tue, 16 Jan 2024 10:39:04 +0200 From: Mike Rapoport To: Jiaxun Yang Cc: linux-mm@kvack.org, Bibo Mao , linux-mips@vger.kernel.org, Paul Burton , Li Xuefeng , Yang Tiezhu , Gao Juxin , Huacai Chen , Huang Pei , Thomas Bogendoerfer , linux-kernel@vger.kernel.org, Yajun Deng Subject: Re: memblock_reserve for unadded region (was: [PATCH] MIPS: loongson64: fix boot failure) Message-ID: References: <20231225093025.23215-1-huangpei@loongson.cn> <731134fd-4b3d-418c-84ee-80646bffcc01@flygoat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <731134fd-4b3d-418c-84ee-80646bffcc01@flygoat.com> On Mon, Jan 15, 2024 at 02:08:21PM +0000, Jiaxun Yang wrote: > Hi mm folks, > > Just a quick question, what is the expected behavior of memblock_reserve > a region that is not added to memblock with memblock_add? > > I'm unable to find any documentation about memblock_reserve in comments and > boot-time-mm, but as per my understanding to the code, this should be a > legit usage? Yes, memblock allows reserving memory that was not added to memblock with memblock_add(). > In practical we run into uninitialized nid of reserved block problem, should > we fix it > in our usage, or on memblock side? Apparently it's a bug in memblock :( If you revert 61167ad5fecd ("mm: pass nid to reserve_bootmem_region()") does the issue disappear? > Thanks > > 在 2023/12/25 09:30, Huang Pei 写道: > > Since commit 61167ad5fecd("mm: pass nid to reserve_bootmem_region()), > > loongson64 booting failed with CONFIG_DEFERRED_STRUCT_PAGE_INIT like > > this: > > ---------------------------------------------------------------------- > > Call Trace: > > [] reserve_bootmem_region+0xa8/0x184 > > [] memblock_free_all+0x104/0x2a8 > > [] mem_init+0x84/0x94 > > [] mm_core_init+0xf8/0x308 > > [] start_kernel+0x43c/0x86c > > > > Code: 10400028 2402fff0 de420000 0203182b 14600022 > > 64420070 00003025 24040003 > > > > ---[ end trace 0000000000000000 ]--- > > Kernel panic - not syncing: Attempted to kill the idle task! > > ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- > > ---------------------------------------------------------------------- > > > > The root cause is no memory region "0x0-0x1fffff" paired with > > memory-reserved region "0x0-0x1fffff" and "0x0-0xfff", with "memblock > > =debug": > > > > ---------------------------------------------------------------------- > > memory[0x0] [0x0000000000200000-0x000000000effffff], > > 0x000000000ee00000 bytes on node 0 flags: 0x0 !!!!here > > memory[0x1] [0x0000000090000000-0x00000000fdffffff], > > 0x000000006e000000 bytes on node 0 flags: 0x0 > > memory[0x2] [0x0000000100000000-0x000000027fffffff], > > 0x0000000180000000 bytes on node 0 flags: 0x0 > > memory[0x3] [0x0000100000000000-0x000010000fffffff], > > 0x0000000010000000 bytes on node 1 flags: 0x0 > > memory[0x4] [0x0000100090000000-0x000010027fffffff], > > 0x00000001f0000000 bytes on node 1 flags: 0x0 > > reserved.cnt = 0x1f > > reserved[0x0] [0x0000000000000000-0x000000000190c80a], > > 0x000000000190c80b bytes flags: 0x0 !!!!oops 0x0-0x1fffff not in memory[0] > > reserved[0x1] [0x000000000190c810-0x000000000190eea3], > > 0x0000000000002694 bytes flags: 0x0 > > ---------------------------------------------------------------------- > > > > It caused memory-reserved region "0x0-0x1fffff" without valid node id > > in "memblock_get_region_node" from "memmap_init_reserved_pages", lead to > > "reserve_bootmem_region-> init_reserved_page -> early_pfn_to_nid()" > > accessing "node_data" out of bound. > > > > To fix this bug, we should remove unnecessary memory block reservation. > > > > +. no need to reserve 0x0-0x1fffff below kernel loading address, since > > it is not registered by "memblock_add_node" > > > > +. no need to reserve 0x0-0xfff for exception handling if it is not > > registered by "memblock_add" either. > > > > Fixes: commit 61167ad5fecd("mm: pass nid to reserve_bootmem_region()) > > Signed-off-by: Huang Pei > > --- > > arch/mips/kernel/traps.c | 3 ++- > > arch/mips/loongson64/numa.c | 2 -- > > 2 files changed, 2 insertions(+), 3 deletions(-) > > > > diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c > > index 246c6a6b0261..9b632b4c10c3 100644 > > --- a/arch/mips/kernel/traps.c > > +++ b/arch/mips/kernel/traps.c > > @@ -2007,7 +2007,8 @@ unsigned long vi_handlers[64]; > > void reserve_exception_space(phys_addr_t addr, unsigned long size) > > { > > - memblock_reserve(addr, size); > > + if(memblock_is_region_memory(addr, size)) > > + memblock_reserve(addr, size); > > } > > void __init *set_except_vector(int n, void *addr) > > diff --git a/arch/mips/loongson64/numa.c b/arch/mips/loongson64/numa.c > > index 8f61e93c0c5b..0f516dde81da 100644 > > --- a/arch/mips/loongson64/numa.c > > +++ b/arch/mips/loongson64/numa.c > > @@ -130,8 +130,6 @@ static void __init node_mem_init(unsigned int node) > > memblock_reserve((node_addrspace_offset | 0xfe000000), > > 32 << 20); > > - /* Reserve pfn range 0~node[0]->node_start_pfn */ > > - memblock_reserve(0, PAGE_SIZE * start_pfn); > > } > > } > > -- > --- > Jiaxun Yang > -- Sincerely yours, Mike.