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 808A037FF40 for ; Fri, 13 Mar 2026 09:23:41 +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=1773393821; cv=none; b=g4b0/GYrc20Ftu1fwiwov5FYa1JNEihzjsW99Y1twn46CHzVdQSRMXY6QBX7SyHU0tQDKZAOHvf+1xhU4CX2DmxkUIMn8N/EtiWnxazPDPNby2/zM7XqEVkFx2spEW7kcib+jK1mA+xsQPDNSumhtVU9+HE7hZx7Jpo3KjHGjdk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773393821; c=relaxed/simple; bh=sfucnBU6UEvHzvnIKr1NLtTw7aZJn+fBBWMo+TGZ9P4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=roYQ4IaXcwjpbc3X0pHk2dbR6oC9CsnkQArQ86WkSQm1HEAy2cradZkmCcuNXUPa1Fk/+O2TagBEDFG7tSQmsNxA/oyciw0ATDnI1aIECe2QCd85k9/lXZ20b2TBtSg7tK+64T0yJSDPpZMPNDX5n+rprnc+EK7WMN/HcbcRDYw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iz5bb8xW; 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="iz5bb8xW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2C5B0C19424; Fri, 13 Mar 2026 09:23:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773393821; bh=sfucnBU6UEvHzvnIKr1NLtTw7aZJn+fBBWMo+TGZ9P4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=iz5bb8xWvwi6aTIWIz/SOjOamX+g9mekNAGNj4x4HLLpeXleW/rcEC79ibN5lA3YK VrD7yL2G7Xaa2p5qq8UFWEkqfswR1hrJEtVkB0FCcK9Dp3cBvBcSZSj4CfP+PxXkdf Djdba4YoLsE4E9oTkOgxpjGgbnKptOZ8xtrTFnH5q4C3TAzyl6Jhdzx+vmFiWtyvkt qqwd6rDZZjBq9kbrXPUOjSuILAekuryPOPukYdt6KBn2EAnmms/0Syzs+UMEK6QYDH 1tW1b2zfRJqED1pfZQ0m4VEHBEzkMb6qczPY3s/JYCGWgp6o/8q+tMykutUIFFZ7Bl K57qsVt8Igoxw== 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, usamaarif642@gmail.com, SeongJae Park , kernel-team@meta.com Subject: Re: [PATCH v8 4/6] kho: fix kho_in_debugfs_init() to handle non-FDT blobs In-Reply-To: <20260309-kho-v8-4-c3abcf4ac750@debian.org> (Breno Leitao's message of "Mon, 09 Mar 2026 06:41:47 -0700") References: <20260309-kho-v8-0-c3abcf4ac750@debian.org> <20260309-kho-v8-4-c3abcf4ac750@debian.org> Date: Fri, 13 Mar 2026 09:23:37 +0000 Message-ID: <2vxz7brggk12.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 09 2026, Breno Leitao wrote: > kho_in_debugfs_init() has two problems when displaying incoming > sub-blobs in debugfs: > > 1. It uses the hardcoded property name "fdt" instead of > KHO_SUB_TREE_PROP_NAME ("preserved-data"), so it never finds > subtrees stored by the current kho_add_subtree(). > > 2. It calls fdt_totalsize() to determine blob sizes, which assumes > all blobs are FDTs. This breaks for non-FDT blobs like struct > kho_kexec_metadata. > > Fix both issues by using KHO_SUB_TREE_PROP_NAME to find subtrees > and reading the "blob-size" property from the FDT (persisted by > kho_add_subtree()) instead of calling fdt_totalsize(). > > Signed-off-by: Breno Leitao Reviewed-by: Pratyush Yadav [...] -- Regards, Pratyush Yadav