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 174A13B5302 for ; Fri, 3 Apr 2026 11:29:12 +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=1775215753; cv=none; b=T2n/wNDMMiOgwehRoe0bph659EDKfs5cCm16eZ9kmjl8X0EddSKirtGMF7ou4+oMB4umRGevGRtwO8AfgglngL2tzpuKLbxM46OibOJUzDuuxVcqpFBwOG8eGJZoy1ppn5GCEhx5Q/J4Oqn7aMtep1yHs33J1OCHe/wJIDh7c04= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775215753; c=relaxed/simple; bh=iE9kV0f3BkfaTSJVskz3DMLc2zztbYk8PO5i/0ZBG9w=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=flFUGZrwK6U+gfNO0neqMKohiqaWVIzETi1e4EnNrqwmW/DpBwK4tYuA7+Yp+T/vIY6HXv8cnepLhMlEL7s/9r31AdC5kHcLu9zjCGggXS0K1MAntufq0A4hdprSkiNOtLjNJhkrRJGVBCBkbZREfu6nraFMUxnKpSkloVurNlw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gU5ih5qs; 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="gU5ih5qs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 20139C4CEF7; Fri, 3 Apr 2026 11:29:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775215752; bh=iE9kV0f3BkfaTSJVskz3DMLc2zztbYk8PO5i/0ZBG9w=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=gU5ih5qsMO7SmY/P80P2pCZSA3Ljhr1wgGtOkuXRGDoq+rIz+QcjTSlK/sPrEsKCm oUL1goaNVxqbB4MMLX6uhuNJZfpz6RzoX3T5bn4RqecI2ztDVlbm9faKl3jI+Pdp1s eC1QyUQOoK9P3iGg7daPKtkTPBmsX4p6HZwM93ETSmtNunlKFMB+4TP1u6mkuFVyIk e9xcN65pIQFA3w+isBLRUffhruy8GD2yLh9kdmTEJyI+0odbknXoz6nNhaii8KOtjj Zq7R9XrNn4LTkoGTTBbB+bDTaBRT0QYPk4ZB3QNlqmyenTSj2bf1sEpBJS67MaPF3a Y8RhyYHey0ZlA== From: Pratyush Yadav To: Breno Leitao Cc: Alexander Graf , Mike Rapoport , Pasha Tatashin , Pratyush Yadav , linux-kernel@vger.kernel.org, kexec@lists.infradead.org, linux-mm@kvack.org, usama.arif@linux.dev, SeongJae Park , kernel-team@meta.com Subject: Re: [PATCH v9 5/6] kho: kexec-metadata: track previous kernel chain In-Reply-To: <20260316-kho-v9-5-ed6dcd951988@debian.org> (Breno Leitao's message of "Mon, 16 Mar 2026 04:54:35 -0700") References: <20260316-kho-v9-0-ed6dcd951988@debian.org> <20260316-kho-v9-5-ed6dcd951988@debian.org> Date: Fri, 03 Apr 2026 11:29:08 +0000 Message-ID: <2vxzika8cmez.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 On Mon, Mar 16 2026, Breno Leitao wrote: > Use Kexec Handover (KHO) to pass the previous kernel's version string > and the number of kexec reboots since the last cold boot to the next > kernel, and print it at boot time. > > Example output: > [ 0.000000] KHO: exec from: 6.19.0-rc4-next-20260107 (count 1) > > Motivation > ========== > > Bugs that only reproduce when kexecing from specific kernel versions > are difficult to diagnose. These issues occur when a buggy kernel > kexecs into a new kernel, with the bug manifesting only in the second > kernel. > > Recent examples include the following commits: > > * commit eb2266312507 ("x86/boot: Fix page table access in > 5-level to 4-level paging transition") > * commit 77d48d39e991 ("efistub/tpm: Use ACPI reclaim memory > for event log to avoid corruption") > * commit 64b45dd46e15 ("x86/efi: skip memattr table on kexec > boot") > > As kexec-based reboots become more common, these version-dependent bugs > are appearing more frequently. At scale, correlating crashes to the > previous kernel version is challenging, especially when issues only > occur in specific transition scenarios. > > Implementation > ============== > > The kexec metadata is stored as a plain C struct (struct kho_kexec_metadata) > rather than FDT format, for simplicity and direct field access. It is > registered via kho_add_subtree() as a separate subtree, keeping it > independent from the core KHO ABI. This design choice: > > - Keeps the core KHO ABI minimal and stable > - Allows the metadata format to evolve independently > - Avoids requiring version bumps for all KHO consumers (LUO, etc.) > when the metadata format changes > > The struct kho_kexec_metadata contains two fields: > - previous_release: The kernel version that initiated the kexec > - kexec_count: Number of kexec boots since last cold boot > > On cold boot, kexec_count starts at 0 and increments with each kexec. > The count helps identify issues that only manifest after multiple > consecutive kexec reboots. > > Acked-by: SeongJae Park > Reviewed-by: Mike Rapoport (Microsoft) > Signed-off-by: Breno Leitao Reviewed-by: Pratyush Yadav [...] -- Regards, Pratyush Yadav