From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from stravinsky.debian.org (stravinsky.debian.org [82.195.75.108]) (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 E20BB3446BC for ; Thu, 22 Jan 2026 12:05:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=82.195.75.108 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769083518; cv=none; b=DxeYKUCJeSb/pwqU9HTXpJfWtrO3Js6end+rUVDI9ZwZvd/SABvIUbohTmUQkR3da9pUiaJZgutAlhHzihZ95PR09zKPZTqTU7LsogXpAZomwQmw2bGuwIbNu9V+JuQ41DzIrcSlD3OdEqwtlI8YaNq56aRLK4Fa/3/VPuUX2A8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769083518; c=relaxed/simple; bh=xOM5YcHUUnDLeV3atzh4bxzc+PHf+i3ykdPU9nB3Fcg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Pfsyd5FsgI25fEJmPDZu/sH6gQ2D0iBMN1gt1rjxixg2ZFQuRIdgUekQlp/i6YCodL8qDuFHo/2slWBBLUi/0+Q9/d3Fca15z/CZ6u1Lbbh19OIfqXsLJuMJLTS+va11eb6PP/hEUb/3s5sM/7wCMdhSMcOinokWPK6WkKIzIDE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org; spf=none smtp.mailfrom=debian.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b=QTR5bMdK; arc=none smtp.client-ip=82.195.75.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=debian.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b="QTR5bMdK" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=SXWW54h4kaUiEYhDhi0tKdenERduKH4QQYXp8ttP4zc=; b=QTR5bMdKKQIdvaXl1F+VY653N5 deoCWEBrVYM5kYB1ioI4txfqaRfnP3/o5wmJR2oU2T/VoDoj7W90huPy6y6/sdm2NEY9ITRF43+6H BeeHRXsBFRICDbM7413O2Nk4PFNOlU+PltnqN1zn7BdK8bsjLCiIwBZDP5UgtdcLdZ9gyGFXPsdNM LFlO8lwU6Bu22ZUYi65aKqLaxdQ0jLgryx5uGf6Gz7fQD/yINQjoqNHFB1SwVURunmeLGEAu0DPWT 2JpJ9B9zf/hnKHZwWQ+jxU6KqB48S7sq2G8Edw4/CNsvZD+pF/go4hXkmlLs+/PP92bSZG0F5tsW+ sHvLYNBQ==; Received: from authenticated user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2) (envelope-from ) id 1vitQq-00D0EE-OM; Thu, 22 Jan 2026 12:05:01 +0000 Date: Thu, 22 Jan 2026 04:04:55 -0800 From: Breno Leitao To: Mike Rapoport Cc: Alexander Graf , Pasha Tatashin , Pratyush Yadav , linux-kernel@vger.kernel.org, kexec@lists.infradead.org, linux-mm@kvack.org, usamaarif642@gmail.com, rmikey@meta.com, clm@fb.com, riel@surriel.com, kernel-team@meta.com, SeongJae Park Subject: Re: [PATCH v4] kho: kexec-metadata: track previous kernel chain Message-ID: References: <20260121-kho-v4-1-5c8fe77b6804@debian.org> 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: X-Debian-User: leitao Hello Mike, On Thu, Jan 22, 2026 at 12:57:50PM +0200, Mike Rapoport wrote: > > +/** > > + * DOC: Kexec Metadata ABI > > + * > > It would be nice to link it from Documentation/ as well ;-) Ack! I am planning something as: commit 90e098ca0d611b44594f08e50ba1cff3c932dd2b Author: Breno Leitao Date: Thu Jan 22 03:47:23 2026 -0800 kho: document kexec-metadata tracking feature Add documentation for the kexec-metadata feature that tracks the previous kernel version and kexec boot count across kexec reboots. This helps diagnose bugs that only reproduce when kexecing from specific kernel versions. Suggested-by: Mike Rapoport Signed-off-by: Breno Leitao diff --git a/Documentation/admin-guide/mm/kho.rst b/Documentation/admin-guide/mm/kho.rst index 6dc18ed4b8861..1faf2c3ba4620 100644 --- a/Documentation/admin-guide/mm/kho.rst +++ b/Documentation/admin-guide/mm/kho.rst @@ -113,3 +113,42 @@ stabilized. ``/sys/kernel/debug/kho/in/sub_fdts/`` Similar to ``kho/out/sub_fdts/``, but contains sub FDT blobs of KHO producers passed from the old kernel. + +Kexec Metadata +============== + +KHO automatically tracks metadata about the kexec chain, passing information +about the previous kernel to the next kernel. This feature helps diagnose +bugs that only reproduce when kexecing from specific kernel versions. + +On each KHO kexec, the kernel logs the previous kernel's version and the +number of kexec reboots since the last cold boot:: + + [ 0.000000] KHO: exec from: 6.19.0-rc4-next-20260107 (count 1) + +The metadata includes: + +``previous_release`` + The kernel version string (from ``uname -r``) of the kernel that + initiated the kexec. + +``kexec_count`` + The number of kexec boots since the last cold boot. On cold boot, + this counter starts at 0 and increments with each kexec. This helps + identify issues that only manifest after multiple consecutive kexec + reboots. + +Use Cases +--------- + +This metadata is particularly useful for debugging kexec transition bugs, +where a buggy kernel kexecs into a new kernel and the bug manifests only +in the second kernel. Examples of such bugs include: + +- Memory corruption from the previous kernel affecting the new kernel +- Incorrect hardware state left by the previous kernel +- Firmware/ACPI state issues that only appear in kexec scenarios + +At scale, correlating crashes to the previous kernel version enables +faster root cause analysis when issues only occur in specific kernel +transition scenarios. > > diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c > > ... > > > static __init int kho_init(void) > > { > > const void *fdt = kho_get_fdt(); > > @@ -1357,6 +1413,15 @@ static __init int kho_init(void) > > if (err) > > goto err_free_fdt; > > > > + if (fdt) > > + kho_process_kexec_metadata(); > > Can't we move it into the existing if (fdt) below? Unfortunately, that won't work due to a data dependency between the two functions. kho_process_kexec_metadata() reads from the FDT subtree and populates kho_in: Basically: kho_in.kexec_count = metadata->kexec_count; While kho_populate_kexec_metadata() increments metadata->kexec_count: /* kho_in.kexec_count is set to 0 on cold boot */ metadata->kexec_count = kho_in.kexec_count + 1; If kho_process_kexec_metadata() is moved after kho_populate_kexec_metadata(), the count would always increment from 0 to 1, ignoring whatever was passed in the FDT. Restructuring to call kho_in_debugfs_init() earlier also doesn't work: if (fdt) { kho_in_debugfs_init(&kho_in.dbg, fdt); kho_process_kexec_metadata(); return 0; } /* Populate kexec metadata for the possible next kexec */ err = kho_populate_kexec_metadata(); if (err) pr_warn("failed to initialize kexec-metadata subtree: %d\n", err); This would return early without populating the kexec metadata for the next kexec, breaking the chain on KHO boots. Please let me know if I am missing any other option. > > + > > + /* Populate kexec metadata for the possible next kexec */ > > + err = kho_populate_kexec_metadata(); > > + if (err) > > + pr_warn("failed to initialize kexec-metadata subtree: %d\n", > > + err); > > Please follow if (err) goto err_ pattern. > > kho_populate_kexec_metadata() failure essentially means that we failed to > allocate memory. This shouldn't happen that early in boot, but if it did, > then something is utterly wrong. Ack! Thanks for the review, --breno