From mboxrd@z Thu Jan 1 00:00:00 1970 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 5774E2F0C7E for ; Thu, 4 Dec 2025 17:52:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764870770; cv=none; b=SO6VCHJVwon1QUG88aKTnRWJvIgSn7rht+WuXFEuah3G8ImPUR4bxruLYIHisf/xhP3z6IEIfcyAERpO02ooaX4cHg+Rzsh5RT43frRW9W18VzLPCGEnVnTJvuj6o2OwoYI4J2Ot8UQasidq7EddYsS4/uExUcHplOPH9w6Gync= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764870770; c=relaxed/simple; bh=DA9sJvA5tPMf3L1jBZwxHdfTxY+amIPbtGepu9VIEh4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kOMp4Bq97KbQuVoXEvWh8f/4mk1uzJQRrvMu/V8kwyZn2bot/tAYQE2B8j+6QlzOdVWSwO33l5XaHIp1VPfZDT2gs/Y4+IRIDsgQ16Pitv+CZznD8gprXnaRDQBz5lxgWa8RtNjncVat+0djWm3G05qajH+wLeXVKglmyOA78wY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OEprNUEv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OEprNUEv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8ED49C4CEFB; Thu, 4 Dec 2025 17:52:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764870769; bh=DA9sJvA5tPMf3L1jBZwxHdfTxY+amIPbtGepu9VIEh4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OEprNUEvW8qmIDYNlWFM/AsLXrtGLg2ss4MYpjzKW1LYFPYkt9h93qnZxylHoslXC IoPZKIHV88WcjIIfkywxKNnEur7UY9hIWAS1g5R7MZCRplpAnwCcKEoqi33oDQaXWP X+8DpHBAMDmYgLCdBRhiym+ogD6AE3Gyfe58ZHInmwwm5D2ZXkEdwavlMHj3gpYRaJ joDiliqQbezPP2qqZCRUtc9M4UrZfNbuLAIGJuX5V6uXwijLengdS5M64cklc1TpNS 3GNOfNCW6eEKFL4LZ/Yie+bzoUu5lj0lLMS+ODRPv6fOLfOVLISuJOo0k3I7L8Fwul RzpIFh6w4QVYA== Date: Thu, 4 Dec 2025 19:52:41 +0200 From: Mike Rapoport To: Usama Arif Cc: Pasha Tatashin , Andrew Morton , kas@kernel.org, changyuanl@google.com, graf@amazon.com, leitao@debian.org, thevlad@meta.com, pratyush@kernel.org, dave.hansen@linux.intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH v3 2/2] mm/memblock: only mark/clear KHO scratch memory when needed Message-ID: References: <20251128173257.969322-1-usamaarif642@gmail.com> <20251128173257.969322-3-usamaarif642@gmail.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: Hi Usama, On Thu, Dec 04, 2025 at 02:51:00PM +0000, Usama Arif wrote: > > On Sun, Nov 30, 2025 at 3:52 AM Mike Rapoport wrote: > >> > >> On Fri, Nov 28, 2025 at 05:29:34PM +0000, Usama Arif wrote: > >>> The scratch memory for kexec handover is used to bootstrap the > >>> kexec'ed kernel. Only the 1st 1MB is used as scratch, and its a > >>> hack to get around limitations with KHO. It is only needed when > >>> CONFIG_KEXEC_HANDOVER is enabled and only if it is a KHO boot > >>> (both checked by is_kho_boot). Add check to prevent marking a KHO > >>> scratch region unless needed. > >> > >> I'm going to rewrite the changelog and queue this for upstream: > >> > >> The scratch memory for kexec handover is used to bootstrap the kexec'ed > >> kernel and it is only needed when it is a KHO boot, i.e. a kexec boot with > >> handover data passed from the previous kernel. > >> > >> Currently x86 marks the first megabyte of memory as KHO scratch even for > >> non-KHO boots if CONFIG_KEXEC_HANDOVER is enabled. > >> > >> Add check to prevent marking a KHO scratch regions unless they are actually > >> needed. > >> > >>> Fixes: a2daf83e10378 ("x86/e820: temporarily enable KHO scratch for memory below 1M") > >>> Reported-by: Vlad Poenaru > >>> Signed-off-by: Usama Arif > >>> Reviewed-by: Pratyush Yadav > > > > This patch causes panic with my tests in linux-next. > > > > [ 0.000000] Kernel panic - not syncing: Cannot allocate 17280 bytes > > for node 0 data > > [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted > > 6.18.0-next-20251203 #2 PREEMPT(undef) > > [ 0.000000] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), > > BIOS 0.1 11/11/2019 > > [ 0.000000] Call Trace: > > [ 0.000000] > > [ 0.000000] ? dump_stack_lvl+0x4e/0x70 > > [ 0.000000] ? vpanic+0xcf/0x2b0 > > [ 0.000000] ? panic+0x66/0x66 > > [ 0.000000] ? alloc_node_data+0x32/0x90 > > [ 0.000000] ? numa_register_nodes+0x82/0x100 > > [ 0.000000] ? numa_init+0x36/0x120 > > [ 0.000000] ? setup_arch+0x667/0x7f0 > > [ 0.000000] ? start_kernel+0x58/0x640 > > [ 0.000000] ? x86_64_start_reservations+0x24/0x30 > > [ 0.000000] ? x86_64_start_kernel+0xc5/0xd0 > > [ 0.000000] ? common_startup_64+0x13e/0x148 > > [ 0.000000] > > [ 0.000000] ---[ end Kernel panic - not syncing: Cannot allocate > > 17280 bytes for node 0 data ]--- > > PANIC: early exception 0x0d IP 10:ffffffff89007a13 error 763 cr2 > > 0xffff991090a01000 > > > > Thanks for reporting this and sorry for the bug! > > So the patch was designed to remove the memblock_mark_kho_scratch in e820__memblock_setup if not > in KHO boot. But it broke memblock_mark_kho_scratch in kho_populate. > Moving kho_in.fdt_phys = fdt_phys to before the memblock_mark_scratch > should fix it. I dont have a setup where I can easily test KHO, but I think below > should fix it? This might, but this is too late for v6.19-rc1. For now I'm dropping this series from memblock/for-next. We can resume working on this after merge window closes. > TBH using fdt_phys to check if the boot is KHO might be a bit hacky? Is it possible > to have a better check for this? Presence of KHO FDT is a clear indication that it is a KHO boot. The issue is that during early boot ordering is hard and it's not always clear in which order features and configuration are detected and used. > diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c > index 9dc51fab604f1..c331749e6452e 100644 > --- a/kernel/liveupdate/kexec_handover.c > +++ b/kernel/liveupdate/kexec_handover.c > @@ -1483,6 +1483,7 @@ void __init kho_populate(phys_addr_t fdt_phys, u64 fdt_len, > goto out; > } > > + kho_in.fdt_phys = fdt_phys; > /* > * We pass a safe contiguous blocks of memory to use for early boot > * purporses from the previous kernel so that we can resize the > @@ -1513,7 +1514,6 @@ void __init kho_populate(phys_addr_t fdt_phys, u64 fdt_len, > */ > memblock_set_kho_scratch_only(); > > - kho_in.fdt_phys = fdt_phys; > kho_in.scratch_phys = scratch_phys; > kho_scratch_cnt = scratch_cnt; > pr_info("found kexec handover data.\n"); > @@ -1524,7 +1524,10 @@ void __init kho_populate(phys_addr_t fdt_phys, u64 fdt_len, > if (scratch) > early_memunmap(scratch, scratch_len); > if (err) > + { > + kho_in.fdt_phys = 0; > pr_warn("disabling KHO revival: %d\n", err); > + } > } -- Sincerely yours, Mike.