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 F30923CE4B1 for ; Tue, 7 Apr 2026 16:09:16 +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=1775578157; cv=none; b=PNJ1um1r2onyETHU6uEvu1G3IVS1ri7Yai2tqLglZcpndRvAbTdJQM4vXntMj4TH7J2okrbnnQnf1uOSZqs10WQQQ7O3MED1mYAquqTGisDy5t7BGXlc4deY8nIj0Ga2waP1dKtolb0A2dkQ/zNx4XMQZc9EpF0ZZifVoRJC10Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775578157; c=relaxed/simple; bh=IZq3eFoH971hNaQ5fWFSLPAm17OKpP60ehLVeEyCFXs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=hSFYEcYMEIH6BaMoGRUlwL065wUFMI27AD4aIrkYlqCa9/gOLTJzUx/o7lX3QyI/O+anC3t5Xbw0vNlNawF29UhsJijElSXd4peIUhaKKqfXYtlpeQX9zFEWsKSCQ6X/ukNGFoyBsbzLnzmwBqnNqNCDmx9+eeDr5wh0xizTkN4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Zg0VQW9G; 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="Zg0VQW9G" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54141C116C6; Tue, 7 Apr 2026 16:09:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775578155; bh=IZq3eFoH971hNaQ5fWFSLPAm17OKpP60ehLVeEyCFXs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Zg0VQW9GzIUTKfH117MbdYQt2PE9Sc4Wr1nEsCmi3Da/xmvEFGTxKHShSUU0LWHX8 X2geS/H8OmV15mGL62gAEYxqx7j55Uw+TapBNrvWuX6xrpgmzbAhiTdKywdkj8tiaj E8d54gLfpkyftc6CjHlXn3HGKymPd3h+4tFOlbQu2KoLSABJlooA6bzhKTwFTCOS+C Tcq/vALCBfoRSHWjIakzvJMjPMt/SY2UfHf/23DhBbCo8lVzCiKXUmYheuxryZqLrT NIPyhEcg9hC4LIqiCuL3J1wXroInDAn7coPgaBhrDN3N+2Mfww22UGKsEbj/VYHGRH tGrftCCULKaCQ== From: Pratyush Yadav To: Pasha Tatashin Cc: Pratyush Yadav , Mike Rapoport , Michal Clapinski , Evangelos Petrongonas , Alexander Graf , Samiullah Khawaja , kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton Subject: Re: [PATCH v7 1/3] kho: make kho_scratch_overlap usable outside debugging In-Reply-To: (Pasha Tatashin's message of "Tue, 7 Apr 2026 10:18:24 -0400") References: <20260317141534.815634-1-mclapinski@google.com> <20260317141534.815634-2-mclapinski@google.com> <2vxz1pgravke.fsf@kernel.org> Date: Tue, 07 Apr 2026 16:09:11 +0000 Message-ID: <2vxzse96ah20.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) 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-Transfer-Encoding: quoted-printable On Tue, Apr 07 2026, Pasha Tatashin wrote: > On Tue, Apr 7, 2026 at 6:55=E2=80=AFAM Pratyush Yadav wrote: >> >> On Wed, Mar 18 2026, Mike Rapoport wrote: >> >> > Hi Michal, >> > >> > On Tue, Mar 17, 2026 at 03:15:32PM +0100, Michal Clapinski wrote: >> >> Also return false if kho_scratch is NULL. >> >> >> [...] >> >> diff --git a/kernel/liveupdate/Makefile b/kernel/liveupdate/Makefile >> >> index d2f779cbe279..dc352839ccf0 100644 >> >> --- a/kernel/liveupdate/Makefile >> >> +++ b/kernel/liveupdate/Makefile >> >> @@ -7,7 +7,6 @@ luo-y :=3D = \ >> >> luo_session.o >> >> >> >> obj-$(CONFIG_KEXEC_HANDOVER) +=3D kexec_handover.o >> >> -obj-$(CONFIG_KEXEC_HANDOVER_DEBUG) +=3D kexec_handover_debug.o >> >> obj-$(CONFIG_KEXEC_HANDOVER_DEBUGFS) +=3D kexec_handover_debu= gfs.o >> >> >> >> obj-$(CONFIG_LIVEUPDATE) +=3D luo.o >> >> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/k= exec_handover.c >> >> index 532f455c5d4f..c9b982372d6e 100644 >> >> --- a/kernel/liveupdate/kexec_handover.c >> >> +++ b/kernel/liveupdate/kexec_handover.c >> >> @@ -820,7 +820,8 @@ int kho_preserve_folio(struct folio *folio) >> >> const unsigned long pfn =3D folio_pfn(folio); >> >> const unsigned int order =3D folio_order(folio); >> >> >> >> - if (WARN_ON(kho_scratch_overlap(pfn << PAGE_SHIFT, PAGE_SIZE << = order))) >> >> + if (WARN_ON(kho_scratch_overlap_debug(pfn << PAGE_SHIFT, >> >> + PAGE_SIZE << order))) >> > >> > Can't say I'm fond of kho_scratch_overlap_debug(). How about we make it >> > >> > if (IS_ENABLED(CONFIG_KEXEC_HANDOVER_DEBUG) && >> > WARN_ON(kho_scratch_overlap(...)) >> >> +1. And we can get rid of kexec_handover_debug.c, for now at least. We >> can add it back when we have something else to put in there. > > Are you proposing moving kho_scratch_overlap() into kexec_handover.c? > That would make it uglier to have #ifdefs in the C file. If you mean > removing this function entirely, I think that is too dangerous because > we have already had a memory corruption issue [1] that was challenging > to root cause, and having this simple check prevents this from > occurring going forward. The problem is that changes to defences such > as kfence, kasan, and asi are happening outside of the core KHO code, > and it is very easy to miss when something unexpectedly causes a > preservation from the scratch area, as we have seen this with kfence. > Worst of all, some of those mitigations use randomized or sampling > approaches and might not be reproducible on every try, so having a > CONFIG that tests it every time in a debug build is the only solid > defense against that. I think you miss the context here. This patchset uses kho_scratch_overlap() during MM init to set the migrate type of pageblocks. So it will no longer be gated by CONFIG_KEXEC_HANDOVER_DEBUG, but by CONFIG_KEXEC_HANDOVER instead. So there is no need for any #ifdefs. All we need to change is to have the debug checks gated with a IS_ENABLED(CONFIG_KEXEC_HANDOVER_DEBUG). So the function stays around, and so do the debug checks. Since core KHO now uses this function, we just move it out to the main file. And since kexec_handover_debug.c has nothing else, we can delete it for now. Anyway, based on the discussion it looks like people want to ask memblock directly and not use kho_scratch_overlap(), so the next version might not have this patch at all. > > Pasha > > [1] https://lore.kernel.org/all/20251021000852.2924827-1-pasha.tatashin@s= oleen.com > >> >> > >> >> return -EINVAL; >> >> >> >> return kho_radix_add_page(tree, pfn, order); >> [...] >> >> -- >> Regards, >> Pratyush Yadav --=20 Regards, Pratyush Yadav