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 018B838AC64; Tue, 10 Mar 2026 21:36:09 +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=1773178570; cv=none; b=g/oRt8gTQmo5qVO/OtVa1DTxChnA8l+IvWruyBWOmrGSeg08EpYX+y498mQ8Lx8QzUgZ4WX06jS8rV6E9vWh9pPFl+x4o5qoXSIPm4NvgHaaK3XrJTVQATHkah+RZV/IUEWzyhUkBe6MHZw+374TpqobU6dsVLWVhi3tsjKBOIw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773178570; c=relaxed/simple; bh=Xg4CGBK3u8/ArgMip1X0dYT6v82ryRISxkCSzREkPSY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YyA7XzZa8/rjYNwqKeKZbs3acCpeVhvd8EzU6us+K7MIAaaXRAlDMDOgZDpo+0E9zOL9fyLuGrP3foHw7GYXyfqvlmbIhMecUzz7Xg/8xTdOrwXiAz6gT2T2GeZegQAdSoWJFboyB+myizpds3XGsPUVx4QxSprpyVeSnxWEbqs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rFsrzVKi; 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="rFsrzVKi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 47922C19423; Tue, 10 Mar 2026 21:36:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773178569; bh=Xg4CGBK3u8/ArgMip1X0dYT6v82ryRISxkCSzREkPSY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rFsrzVKiD8VQjeGuN+nEd00lZPd0I4jL+qZRfGtN3x1gIsiu+MJ8jFnr83Y+560yY SpEl2asG9qxhQgwS/T+7OdXOjJP4Uie/qk7vLBGXJ0YEdOMD+VtIK3iVBP5xb5t+sR AWlWnw+zk3tSDoW3EImfYu5Du8Uy4F2++O1V2FGVqKKSjV9YKUWJsj37oEu5TaaYv0 h0LIbjKFNgwn0zf9efYj16MNz7kz27oGqtw+c1YEGZVjJ1TxHDJwF3v+Gs1h4mihps jFoLf8wbuiKkjVBnQqE0JrNES33AIWTX6ZkcyETw1CBNFaoCmmu6oY8B5yjWBz8zag 9wnK1qInBajjw== Date: Tue, 10 Mar 2026 14:36:06 -0700 From: Eric Biggers To: Thomas =?iso-8859-1?Q?Wei=DFschuh?= Cc: Nathan Chancellor , Arnd Bergmann , Luis Chamberlain , Petr Pavlu , Sami Tolvanen , Daniel Gomez , Paul Moore , James Morris , "Serge E. Hallyn" , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Naveen N Rao , Mimi Zohar , Roberto Sassu , Dmitry Kasatkin , Eric Snowberg , Nicolas Schier , Daniel Gomez , Aaron Tomlin , "Christophe Leroy (CS GROUP)" , Nicolas Schier , Nicolas Bouchinet , Xiu Jianfeng , Fabian =?iso-8859-1?Q?Gr=FCnbichler?= , Arnout Engelen , Mattia Rizzolo , kpcyrd , Christian Heusel , =?iso-8859-1?Q?C=E2ju?= Mihai-Drosi , Sebastian Andrzej Siewior , linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-modules@vger.kernel.org, linux-security-module@vger.kernel.org, linux-doc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-integrity@vger.kernel.org Subject: Re: [PATCH v4 06/17] kbuild: add stamp file for vmlinux BTF data Message-ID: <20260310213606.GD120274@quark> References: <20260113-module-hashes-v4-0-0b932db9b56b@weissschuh.net> <20260113-module-hashes-v4-6-0b932db9b56b@weissschuh.net> 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260113-module-hashes-v4-6-0b932db9b56b@weissschuh.net> On Tue, Jan 13, 2026 at 01:28:50PM +0100, Thomas Weißschuh wrote: > The upcoming module hashes functionality will build the modules in > between the generation of the BTF data and the final link of vmlinux. > Having a dependency from the modules on vmlinux would make this > impossible as it would mean having a cyclic dependency. > Break this cyclic dependency by introducing a new target. > > Signed-off-by: Thomas Weißschuh > --- > scripts/Makefile.modfinal | 4 ++-- > scripts/link-vmlinux.sh | 6 ++++++ > 2 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/scripts/Makefile.modfinal b/scripts/Makefile.modfinal > index 149e12ff5700..adfef1e002a9 100644 > --- a/scripts/Makefile.modfinal > +++ b/scripts/Makefile.modfinal > @@ -56,8 +56,8 @@ if_changed_except = $(if $(call newer_prereqs_except,$(2))$(cmd-check), \ > printf '%s\n' 'savedcmd_$@ := $(make-cmd)' > $(dot-target).cmd, @:) > > # Re-generate module BTFs if either module's .ko or vmlinux changed > -%.ko: %.o %.mod.o .module-common.o $(objtree)/scripts/module.lds $(and $(CONFIG_DEBUG_INFO_BTF_MODULES),$(KBUILD_BUILTIN),$(objtree)/vmlinux) FORCE > - +$(call if_changed_except,ld_ko_o,$(objtree)/vmlinux) > +%.ko: %.o %.mod.o .module-common.o $(objtree)/scripts/module.lds $(and $(CONFIG_DEBUG_INFO_BTF_MODULES),$(KBUILD_BUILTIN),$(objtree)/.tmp_vmlinux_btf.stamp) FORCE > + +$(call if_changed_except,ld_ko_o,$(objtree)/.tmp_vmlinux_btf.stamp) > ifdef CONFIG_DEBUG_INFO_BTF_MODULES > +$(if $(newer-prereqs),$(call cmd,btf_ko)) > endif > diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh > index 4ab44c73da4d..8c98f8645a5c 100755 > --- a/scripts/link-vmlinux.sh > +++ b/scripts/link-vmlinux.sh > @@ -111,6 +111,7 @@ vmlinux_link() > gen_btf() > { > local btf_data=${1}.btf.o > + local btf_stamp=.tmp_vmlinux_btf.stamp > > info BTF "${btf_data}" > LLVM_OBJCOPY="${OBJCOPY}" ${PAHOLE} -J ${PAHOLE_FLAGS} ${1} > @@ -131,6 +132,11 @@ gen_btf() > fi > printf "${et_rel}" | dd of="${btf_data}" conv=notrunc bs=1 seek=16 status=none > > + info STAMP $btf_stamp > + if ! cmp --silent $btf_data $btf_stamp; then > + cp $btf_data $btf_stamp > + fi A "stamp file" is traditionally an empty file that is written when some build step has completed. The above code is instead copying the entire .tmp_vmlinux1.btf.o file (megabytes in size) to .tmp_vmlinux_btf.stamp. So, it's not clear to me why the stamp file is needed at all, versus depending directly on .tmp_vmlinux1.btf.o. I guess 'make' doesn't know about the dependencies of .tmp_vmlinux1.btf.o. But the same is true of the stamp file, right? So either way, how would 'make' know to finish rebuilding the file before starting to execute the "Re-generate module BTFs" rule? Also, passing the long option '--silent' to 'cmp' creates a dependency on the GNU implementation of 'cmp', which isn't documented as a kernel build dependency. Probably better to use the short option '-s'. Also, the stamp file isn't being deleted by 'make clean'. It looks like it would need to be added to cleanup() in link-vmlinux.sh. - Eric