From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-186.mta1.migadu.com (out-186.mta1.migadu.com [95.215.58.186]) (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 A85426A33B for ; Mon, 19 Jan 2026 07:05:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.186 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768806324; cv=none; b=kXdjD3//KjxA+c+A5SgzbMhE8QNHIZQTwzQ7dKSWhKACN1mvFXhkkswGHzTUtD3eFAs/YG5weqBwRNwJJdWLjPb+kDb+8pFXCkigpNUZGYfjAZvPIZ8lYwQ8fyTBAFwDuDOBP4Dl5q0nASPbzcEn2+lVj7vOqIGHihJhX6cXh0w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768806324; c=relaxed/simple; bh=Km87+CB5UTAoi3DMtGh7GQ+9L1wDKZ81fJU4pfs+7ys=; h=Message-ID:Date:MIME-Version:Subject:To:References:From: In-Reply-To:Content-Type; b=jeOjp6cgAx4fWlZRwpjTZNsRBQYhyD9oH7EL4Pa9zFHS5jTBxT5jfd7mgdY4/0SkvkAlQEh6usZzCHhtDaQhcdh5UyRaqZLXkFmowi4ShzQM+f6ean7xnLHflylKyRh89prVBLKD226DMCOYMaxiKNCiuDKxK/eXAWyr4W5NnTA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=EvclKCuZ; arc=none smtp.client-ip=95.215.58.186 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="EvclKCuZ" Message-ID: <4f7e180d-f7bb-4a21-ae2b-f42cc969401d@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1768806319; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bb3xkMpeNpnybd9Na8Isc5XENxO7ZKbU0IXQYY84igE=; b=EvclKCuZlg7ifGbmHKL+RgT9befhs9UroGPdqC0TP0IrHcmdjq9+EpZElp1YHgXCPiJOqW 7jzdt7ISwzQe3wrIIT70lxeL53lrGIAO9uNztt6xjt+fBF5mtZcojqTM+XY+8uVo3JYubs fUY1C5COy2sskFonjvKYshEUIVRZ1NA= Date: Sun, 18 Jan 2026 23:04:58 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v4] kho: validate preserved memory map during population To: Pasha Tatashin , akpm@linux-foundation.org, rppt@kernel.org, graf@amazon.com, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, linux-mm@kvack.org, pratyush@kernel.org, ricardo.neri-calderon@linux.intel.com References: <20251223140140.2090337-1-pasha.tatashin@soleen.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Zhu Yanjun In-Reply-To: <20251223140140.2090337-1-pasha.tatashin@soleen.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT 在 2025/12/23 6:01, Pasha Tatashin 写道: > If the previous kernel enabled KHO but did not call kho_finalize() > (e.g., CONFIG_LIVEUPDATE=n or userspace skipped the finalization step), > the 'preserved-memory-map' property in the FDT remains empty/zero. > > Previously, kho_populate() would succeed regardless of the memory map's > state, reserving the incoming scratch regions in memblock. However, > kho_memory_init() would later fail to deserialize the empty map. By that > time, the scratch regions were already registered, leading to partial > initialization and subsequent list corruption (freeing scratch area > twice) during kho_init(). > > Move the validation of the preserved memory map earlier into > kho_populate(). If the memory map is empty/NULL: > 1. Abort kho_populate() immediately with -ENOENT. > 2. Do not register or reserve the incoming scratch memory, allowing the new > kernel to reclaim those pages as standard free memory. > 3. Leave the global 'kho_in' state uninitialized. > > Consequently, kho_memory_init() sees no active KHO context > (kho_in.mem_chunks_phys is 0) and falls back to kho_reserve_scratch(), > allocating fresh scratch memory as if it were a standard cold boot. > > Fixes: de51999e687c ("kho: allow memory preservation state updates after finalization") > Reported-by: Ricardo Neri > Closes: https://lore.kernel.org/all/20251218215613.GA17304@ranerica-svr.sc.intel.com > Signed-off-by: Pasha Tatashin > Reviewed-by: Mike Rapoport (Microsoft) > Tested-by: Ricardo Neri > --- > Changes v4: > - Addressed Tested-by > - Addressed review comments from Pratyush. > > kernel/liveupdate/kexec_handover.c | 37 +++++++++++++++--------------- > 1 file changed, 19 insertions(+), 18 deletions(-) > > diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c > index 9dc51fab604f..d4482b6e3cae 100644 > --- a/kernel/liveupdate/kexec_handover.c > +++ b/kernel/liveupdate/kexec_handover.c > @@ -460,27 +460,23 @@ static void __init deserialize_bitmap(unsigned int order, > } > } > > -/* Return true if memory was deserizlied */ > -static bool __init kho_mem_deserialize(const void *fdt) > +/* Returns physical address of the preserved memory map from FDT */ > +static phys_addr_t __init kho_get_mem_map_phys(const void *fdt) > { > - struct khoser_mem_chunk *chunk; > const void *mem_ptr; > - u64 mem; > int len; > > mem_ptr = fdt_getprop(fdt, 0, PROP_PRESERVED_MEMORY_MAP, &len); > if (!mem_ptr || len != sizeof(u64)) { > pr_err("failed to get preserved memory bitmaps\n"); > - return false; > + return 0; > } > > - mem = get_unaligned((const u64 *)mem_ptr); > - chunk = mem ? phys_to_virt(mem) : NULL; > - > - /* No preserved physical pages were passed, no deserialization */ > - if (!chunk) > - return false; > + return get_unaligned((const u64 *)mem_ptr); > +} > > +static void __init kho_mem_deserialize(struct khoser_mem_chunk *chunk) > +{ > while (chunk) { > unsigned int i; > > @@ -489,8 +485,6 @@ static bool __init kho_mem_deserialize(const void *fdt) > &chunk->bitmaps[i]); > chunk = KHOSER_LOAD_PTR(chunk->hdr.next); > } > - > - return true; > } > > /* > @@ -1253,6 +1247,7 @@ bool kho_finalized(void) > struct kho_in { > phys_addr_t fdt_phys; > phys_addr_t scratch_phys; > + phys_addr_t mem_map_phys; > struct kho_debugfs dbg; > }; > > @@ -1434,12 +1429,10 @@ static void __init kho_release_scratch(void) > > void __init kho_memory_init(void) > { > - if (kho_in.scratch_phys) { > + if (kho_in.mem_map_phys) { > kho_scratch = phys_to_virt(kho_in.scratch_phys); > kho_release_scratch(); > - > - if (!kho_mem_deserialize(kho_get_fdt())) > - kho_in.fdt_phys = 0; > + kho_mem_deserialize(phys_to_virt(kho_in.mem_map_phys)); > } else { > kho_reserve_scratch(); > } > @@ -1448,8 +1441,9 @@ void __init kho_memory_init(void) > void __init kho_populate(phys_addr_t fdt_phys, u64 fdt_len, > phys_addr_t scratch_phys, u64 scratch_len) > { > - void *fdt = NULL; > struct kho_scratch *scratch = NULL; > + phys_addr_t mem_map_phys; > + void *fdt = NULL; > int err = 0; > unsigned int scratch_cnt = scratch_len / sizeof(*kho_scratch); > > @@ -1475,6 +1469,12 @@ void __init kho_populate(phys_addr_t fdt_phys, u64 fdt_len, > goto out; > } > > + mem_map_phys = kho_get_mem_map_phys(fdt); > + if (!mem_map_phys) { > + err = -ENOENT; > + goto out; > + } > + > scratch = early_memremap(scratch_phys, scratch_len); > if (!scratch) { > pr_warn("setup: failed to memremap scratch (phys=0x%llx, len=%lld)\n", > @@ -1515,6 +1515,7 @@ void __init kho_populate(phys_addr_t fdt_phys, u64 fdt_len, > > kho_in.fdt_phys = fdt_phys; > kho_in.scratch_phys = scratch_phys; > + kho_in.mem_map_phys = mem_map_phys; > kho_scratch_cnt = scratch_cnt; > pr_info("found kexec handover data.\n"); > > > base-commit: cc3aa43b44bdb43dfbac0fcb51c56594a11338a8 The base-commit is commit cc3aa43b44bdb43dfbac0fcb51c56594a11338a8 (HEAD -> upstream/master, tag: next-20251219) Author: Stephen Rothwell Date: Fri Dec 19 14:12:19 2025 +1100 Add linux-next specific files for 20251219 Signed-off-by: Stephen Rothwell Now this commit can not be applied to the 6.19-rc5. Zhu Yanjun