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 BBA2C32E724 for ; Mon, 26 Jan 2026 12:01:26 +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=1769428888; cv=none; b=U/My9EQTLZyDy8uUB4DndqrYOoLsmHlvcEt7PMVprzQ973QEg7vv+SfCSuaGtHEYqVe/sdlLNECPbEbs1N4x87s/knrA6gO5WUadn2zqnyhpo7XyhSSKP8MnM3LVmnSdoqaM2m1KXFzjW6K0ZYPmMbzQu4Ryxz3vSNC5C5Z2yZw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769428888; c=relaxed/simple; bh=E8dvzwpH6PkzLc/Z/KkR3bOFskSKrkd3yBWi0q7ByOU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=t3U8x3W/yZNmi1A1S/YyO9bBfQ2v5O1NtoDyfVWB0OeDD9xQHRRSmLi96JTmn1zcRSCDH/dAjqJdeZXY63MpNurJRIJwrBdyx704G7bVNXm6W3OvmcalNV+o3xU2GWPsq7QsyEVfy7nRjS63pdQJJaiXV43hutPNwrpfxr+aVk8= 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=ojjfT47Z; 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="ojjfT47Z" 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=4MD0JKg2XNo8f5Vd/iDuV+WzwyogEWvnQdT2mMRPJPc=; b=ojjfT47ZBr4oqDYV7h38ok75+M p3XiCn2p0xutQKqmEFkIi9mdXHk694M+JEC5A2HSXodenka5ejPAqrEIpS+GR7+MIZKg/GiDrU0h/ cjbkbMVmKAxTCpcV0Crw8twAfmqwO+gHuEy6lwr7KLmPogIciBMC9NUJWI+Ebdv3TldDgNPWnpiAT HHy6CIQ1SvX9w0pxi8AjQb0Z8TmM828eRnvex7+0FFxWR1GdpIbzhJOa7kWgZ8AwzFBqluspmowRM X+gfS40M0dgf5MQOTY1t4JYXTAL3pUvNcF/lTDoq8BGr5sd0PghDaUSZ9FcYbtVbkCkDj5cVeRJOz DXoP1LfA==; 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 1vkLHR-00G9y1-Js; Mon, 26 Jan 2026 12:01:18 +0000 Date: Mon, 26 Jan 2026 04:01:11 -0800 From: Breno Leitao To: Alexander Graf , Mike Rapoport , Pasha Tatashin , Pratyush Yadav Cc: 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: <20260121-kho-v4-1-5c8fe77b6804@debian.org> X-Debian-User: leitao On Wed, Jan 21, 2026 at 06:50:38AM -0800, Breno Leitao wrote: > +static __init int kho_populate_kexec_metadata(void) > +{ > + struct kho_kexec_metadata *metadata; > + int err; > + > + metadata = kho_alloc_preserve(sizeof(*metadata)); > + if (IS_ERR(metadata)) > + return PTR_ERR(metadata); > + > + strscpy(metadata->previous_release, init_uts_ns.name.release, > + sizeof(metadata->previous_release)); > + /* kho_in.kexec_count is set to 0 on cold boot */ > + metadata->kexec_count = kho_in.kexec_count + 1; > + > + err = kho_add_subtree(KHO_METADATA_NODE_NAME, metadata); There is a hidden bug in here when CONFIG_KEXEC_HANDOVER_DEBUGFS is set. kho_add_subtree() expects a fdt as the second argument, and we are passing a pure C struct. That works fine, except for debugfs, which does: 1. kho_add_subtree() calls kho_debugfs_fdt_add() 2. kho_debugfs_fdt_add() calls __kho_debugfs_fdt_add() 3. __kho_debugfs_fdt_add() executes fdt_totalsize(fdt) The fdt_totalsize() macro reads bytes 4-7 of the input as a big-endian u32, and this will hit struct kho_kexec_metadata, given I am passing a C struct instead of a FDT. struct kho_kexec_metadata { char previous_release[__NEW_UTS_LEN + 1]; // 65 bytes u32 kexec_count; } __packed; Bytes 4-7 would be characters from previous_release (e.g., "0-rc" from "6.19.0-rc4..."). Interpreted as big-endian u32, this gives a garbage size value. The alternatives I see here are: 1) Come back to FDT instead of plain C struct, similarly to the previous version [1] 2) Created some helpers to treat C struct fields specially just for this feature, and we can do it later if we have more users. 3) Move this kexec_metadata to work on top of LUO (similarly to memfd), but that would be an unnecessary dependency just to have this kexec_metadata. That said, for the next version, I am coming back to to FDT. Link: https://lore.kernel.org/all/20260108-kho-v3-0-b1d6b7a89342@debian.org/ [1] --breno