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 A0F6274BE1 for ; Sun, 7 Dec 2025 14:57:47 +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=1765119467; cv=none; b=PiQJninjFXAyzWVjFtF4veqdZVKIPsq+PNZjnXwcVcq83wUkGWS1pkI4nbPpcJvBbH6imNh7IdJ648UmU+VCvz8T6Nk0MXswfnRm9Wo27w1wO28xHKBicakX6M2tPN2zS9XOYIEEtb4vGS7jWcsROO+SXbVTLLsq4o1QA3cZ5pk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765119467; c=relaxed/simple; bh=enXFBL70rkMnLzna7QiJ+POgzsVU0iKhU+yZQwRZaXo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=BaaNMH2Ljgr+W9ax0zHUly6SNvaPW1BnY5bCHhm+C8OgaIo9uCUZ0xRkd5/JTbTidJu9yzBS3fa0X1YxQFh7C1q7M0w+mPeKrrAG5ukMny7NNPdmPEA5qh9Mvk2gMgDght3leULh86Dd+IT0i6fkNnnGl45xVbPxVPxNgYvcEnY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EnNrsX5+; 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="EnNrsX5+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8DC7AC4CEFB; Sun, 7 Dec 2025 14:57:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1765119466; bh=enXFBL70rkMnLzna7QiJ+POgzsVU0iKhU+yZQwRZaXo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=EnNrsX5+6w4sCseBHAOR0RSAs2U5X+MFEESUoz+r89S7pcYSdoaWgYgIBDgNdJ7gv 05PFwFSPxSh1ZBMn/4MWwJOPIRGQZd8AIVNHNqOZpmSN6p+9R8DMTUf+di5A2uWQeC 7/BoUJnmi/D5tHyl5D1Q0WuaUDUOggRKN9tMgKigRmMWZkk9XQyJkd1kKEV0RySINX mLazr7V5s6xw+NX5sI8ScPYnI7aWn6qxuso49oliKMmsHUc5917Kgu8SHCGFZuP2Bm umAZjmldgUY4QzdDrcMvadr0ZHjT342T4ozzxydqmp9Rd2B2I/asvoBVrSQAN7hUm7 2lhJZQYdNQ8Hw== Date: Sun, 7 Dec 2025 16:57:38 +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> <657d2356-126d-452b-ba7f-5c0761f4f832@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=us-ascii Content-Disposition: inline In-Reply-To: <657d2356-126d-452b-ba7f-5c0761f4f832@gmail.com> On Thu, Dec 04, 2025 at 07:27:29PM +0000, Usama Arif wrote: > On 04/12/2025 17:52, Mike Rapoport wrote: > >> > >> 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? There's a simple KHO sefltest in tools/testing/selftest/kho > > 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. > > > > Yes makes sense. > > How would you like me to proceed with the fix? Should I send just the fix now, > or these 2 patches plus the fix after the merge window closes? The fix should come before the changes in memblock_mark_kho_scratch(), so please resend the whole series. > >> 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; This should happen before the calls to memblock_mark_kho_scratch(). > >> /* > >> * 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.