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 036AE2D97A5 for ; Fri, 2 Jan 2026 14:05:29 +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=1767362730; cv=none; b=IzLHGXY8ipltQ0JKaq934nxc1WHfEunxW9gF2j2UxgrCEHY6IrqOebh7H4P+aRWkDT5dLpFPKeAkWmVEHM2SCzQI1dF/xnLNG/6GwS2SmANdgm3PgUtFcmXFJh1xluCz/x3Z9a3xe0tovLU1+ngP6fnWsw+W39uGytSCsORO5ro= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767362730; c=relaxed/simple; bh=dHhKBLUj/xPGvd98uQUXe/daqMsBh++bApJj90w3Yok=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=cl4DDmbHcCj2dTKH4cSCvArT84jVFiHRkuaGDJAENzLW8ASl6G6YyUlvvkgrYNXy0VbSgNQf9tW2wFPefsWruIWFrq4npoLkwlkPltx/W9DZ0Mv4CvLbg/2agQuPukYI3f+RSaCCEQGy1/aK660jj3R9odgNMiwnc1BpYeBE8sc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bEXwHj4c; 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="bEXwHj4c" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28A71C116B1; Fri, 2 Jan 2026 14:05:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767362729; bh=dHhKBLUj/xPGvd98uQUXe/daqMsBh++bApJj90w3Yok=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bEXwHj4cDOGyrvCsRQsGDv6yK+YiVcL6Hso7BUrsbYoRlIE0/vU3oyAYugWyBB03N oLvB4x/cV2WbXpQ4eQ2+75+qFzaPNHOYpSE7Al6RyZFb/pH6fcgBWhZLuoTixEY+hG 4vRM1b0DI0my9AcFkYxCHeB3j9IQg2/kzWUkIOUEpkbj19gqZ8W1oeqr2cbKmVdZIj 0avpZ7L87kiJWhEaM0grbGMtsGS6G4xhroO237+78uDg+r3zrCjBegDBITsR6qYRHy Lzyti33d7vz4No+P31u2mk14wPviBN2gkACyXRwsf1yZ0eCAF1j1oIuIH7H1V45Pu5 v0o+rvB5BhZeg== From: Pratyush Yadav To: Pasha Tatashin Cc: Pratyush Yadav , Mike Rapoport , Evangelos Petrongonas , Alexander Graf , Andrew Morton , Jason Miu , linux-kernel@vger.kernel.org, kexec@lists.infradead.org, linux-mm@kvack.org, nh-open-source@amazon.com Subject: Re: [PATCH] kho: add support for deferred struct page init In-Reply-To: (Pasha Tatashin's message of "Tue, 30 Dec 2025 11:05:05 -0500") References: <20251216084913.86342-1-epetron@amazon.de> <861pkpkffh.fsf@kernel.org> <86jyyecyzh.fsf@kernel.org> <863452cwns.fsf@kernel.org> <864ip99f1a.fsf@kernel.org> Date: Fri, 02 Jan 2026 15:05:23 +0100 Message-ID: <861pk885zw.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, Dec 30 2025, Pasha Tatashin wrote: > On Mon, Dec 29, 2025 at 4:03=E2=80=AFPM Pratyush Yadav wrote: >> >> On Tue, Dec 23 2025, Pasha Tatashin wrote: [...] >> > >> > I kind of do not like relying on magic to decide whether to initialize >> > the struct page. I would prefer to avoid this magic marker altogether: >> > i.e. struct page is either initialized or not, not halfway >> > initialized, etc. >> >> The magic is purely sanity checking. It is not used to decide anything >> other than to make sure this is actually a KHO page. I don't intend to >> change that. My point is, if we make sure the KHO pages are properly >> initialized during MM init, then restoring can actually be a very cheap >> operation, where you only do the sanity checking. You can even put the >> magic check behind CONFIG_KEXEC_HANDOVER_DEBUG if you want, but I think >> it is useful enough to keep in production systems too. > > It is part of a critical hotpath during blackout, should really be > behind CONFIG_KEXEC_HANDOVER_DEBUG > >> > Magic is not reliable. During machine reset in many firmware >> > implementations, and in every kexec reboot, memory is not zeroed. The >> > kernel usually allocates vmemmap using exactly the same pages, so >> > there is just too high a chance of getting magic values accidentally >> > inherited from the previous boot. >> >> I don't think that can happen. All the pages are zeroed when >> initialized, which will clear the magic. We should only be setting the >> magic on an initialized struct page. > > This can happen due to bugs when we use a partially initialized > "struct page", something that Mike have been looking to do. So, pass > some information in a struct page before it is fully initialized. The magic is checked at restore time though, and by then all non-KHO pages should be properly initialized and have their magic cleared. Also, the magic is cleared by kho_restore_folio(), so this can only ever happen for pages that were preserved but not restored in the previous boot. I don't think that is a common use case in the first place. [...] --=20 Regards, Pratyush Yadav