From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Kees Cook <kees@kernel.org>
Cc: "Linus Torvalds" <torvalds@linux-foundation.org>,
"Nathan Chancellor" <nathan@kernel.org>,
"Nicolas Schier" <nsc@kernel.org>,
"Nick Desaulniers" <ndesaulniers@google.com>,
"Bill Wendling" <morbo@google.com>,
"Justin Stitt" <justinstitt@google.com>,
"Masahiro Yamada" <masahiroy@kernel.org>,
"Alexey Gladkov" <legion@kernel.org>,
"Thomas Gleixner" <tglx@kernel.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Paul Walmsley" <pjw@kernel.org>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Alexandre Ghiti" <alex@ghiti.fr>,
"Arnd Bergmann" <arnd@arndb.de>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"Ard Biesheuvel" <ardb@kernel.org>,
"Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
"Josh Poimboeuf" <jpoimboe@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Tamir Duberstein" <tamird@kernel.org>,
"Alexandre Courbot" <acourbot@nvidia.com>,
"Onur Özkan" <work@onurozkan.dev>,
"Jonathan Corbet" <corbet@lwn.net>,
"Randy Dunlap" <rdunlap@infradead.org>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
llvm@lists.linux.dev, linux-riscv@lists.infradead.org,
linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-efi@vger.kernel.org, rust-for-linux@vger.kernel.org,
linux-doc@vger.kernel.org, "Jens Axboe" <axboe@kernel.dk>,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH v3 09/20] kbuild: implement and use depcheck to check dependency timestamps
Date: Sat, 19 Sep 2026 18:02:46 +0100 [thread overview]
Message-ID: <aq6_JcIy6gOsN4oa@gremlin> (raw)
In-Reply-To: <202609171229.31BB336E1@keescook>
On Thu, Sep 17, 2026 at 01:59:26PM -0700, Kees Cook wrote:
> On Thu, Sep 17, 2026 at 11:42:50AM -0700, Kees Cook wrote:
> > On Thu, Sep 17, 2026 at 05:06:19PM +0100, Lorenzo Stoakes (ARM) wrote:
> > > This can be done faster in C, so implement scripts/basic/depcheck to do so.
> > >
> > > It does as little work as possible, reading the .cmd files from a
> > > directory's targets and running stat on each dependency only a single time.
> >
> > Doesn't this run the risk of missing transitive deps?
> >
> > C.cmd: C.o depends on A.c and B.c and B.h
> > B.cmd: B.h depends on B.data and B.script
> >
> > depcheck looks at C.o and B.h's times and is happy so it drops C.cmd file,
> > but then see B.script has changed compared to B.h, so it keeps B.cmd,
> > and then the build runs and doesn't have the C.o dep list any more,
> > and C.o goes unbuilt?
> >
> > Also, I don't think this handles if_changed commands at all? The kbuild
> > rebuild condition is timestamps plus if_changed's command-line check.
>
> tl;dr: I spent way too long looking at this. I think my conclusion is
> "Hm, this makes some cases of missed Makefile deps on generated files
> harder to find, but there don't *appear* to be any obviously wrong
> instances of this in the tree."
>
> Long version:
>
> There does appear to be a problem in the case of generated targets where
> the Makefile deps are build-order correct but lack explicit deps. As
> in, a clean build generates the needed dependencies due to some prior
> explicit Makefile rule dependency, and a later source-level "#include"
> for the generated file exists (and the build doesn't fail since the
> included file got generated before the source that "#include"d it got
> built), and then the normal dep tracking (-Wp,-MMD,... -> .cmd) catches
> it and any direct changes to that dep would normally get noticed going
> forward on incremental builds.
>
> However, with the depcheck .cmd pruning, changes to transitive deps
> (either via file contents or Kconfig options) will go unnoticed during
> incremental builds without that explicit dep (but stock doesn't miss
> it). Though actually it's kind of worse because it'll get noticed on
> rebuild #N+1 for N level of transitive depth, so something will break,
> and then you build again, and the changes from 2 builds ago suddenly
> get rebuilt...
>
> I think you maybe encountered an instance of this in your series, too,
> but it got exposed due to a clean build no longer having the ordering
> correct:
> https://lore.kernel.org/lkml/20260917-build-speedup-v3-18-9ecf4163ff36@kernel.org/
>
> See the trailing diff for a demo:
>
>
> git apply demo.diff
> make O=b defconfig
> # simulate a earlier-stage header generation...
> make O=b lib/byfile_anchor.o lib/byconf_anchor.o
> make O=b lib/
>
> # trigger 1: the header's input file changes
> echo FROMFILE-two > lib/byfile_gen.in
> make O=b lib/
>
> # trigger 2: a Kconfig value changes; no file is touched
> ./scripts/config --file b/.config --set-str LOCALVERSION -demo2
> make O=b lib/
>
> # what each object ended up holding
> strings b/lib/byfile_anchor.o | grep FROMFILE- # FROMFILE-two both trees
> strings b/lib/byfile_victim.o | grep FROMFILE- # FROMFILE-two stock
> # FROMFILE-one patched <-- stale
>
> strings b/lib/byconf_anchor.o | grep CONF- # CONF--demo2 both trees
> strings b/lib/byconf_victim.o | grep CONF- # CONF--demo2 stock
> # CONF- patched <-- stale
>
>
> This means adding depcheck would silently expose any current (and future)
> missing explicit deps on generated files where those files get generated
> by either an earlier build stage or an earlier rule. :(
>
> I went looking for the kind of missed Makefile dep for a generated file,
> and while it's not a very grep-able condition, I did look at stuff that
> fell into include/generated/, but it's safe due to the prepare/archprepare
> ordering AFAICT. So then I looked at places where -I had $(obj) added to
> it, and all of those seemed to have explicit Makefile deps too. Well, all
> except for arch/x86/boot/compressed/sev-handle-vc.c which includes
> "../../lib/inat.c" but that seems safe today due to ordering from
> arch/x86/lib/ being needed before arch/x86/boot/compressed/.
>
> So, yeah, it makes me nervous, and it may make incremental builds less
> idempotent. But I can't really find extant problems and the demo is
> slightly contrived, but not exactly an impossible situation.
Ack thanks for this!
There is definitely an issue here, your example is fine in the stock kernel
but one run late in v3.
Solution is to have depcheck treat any dependency that is itself a target
of the same run as never being 'fresh' (it already reads every .cmd file in
the directory so has all the dependency information it needs), so that's
fixed in v4.
Confirmed that it fixes the demo'd bug here, that touching a header
rebuilds exactly the same objects as it did before and that noop build perf
was not harmed by the change.
>
> -Kees
>
>
> diff --git a/lib/Makefile b/lib/Makefile
> index dfab958327c5c..aed0bd9eb7d6a 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -350,3 +350,36 @@ CONTEXT_ANALYSIS_test_context-analysis.o := y
> obj-$(CONFIG_CONTEXT_ANALYSIS_TEST) += test_context-analysis.o
>
> subdir-$(CONFIG_FORTIFY_SOURCE) += test_fortify
> +
> +# --- depcheck demo ---
> +obj-y += byfile_anchor.o byfile_victim.o byconf_anchor.o byconf_victim.o
> +
> +quiet_cmd_byfile = GENFILE $@
> + cmd_byfile = printf '\#define BYFILE_STR "%s"\n' "$$(cat $<)" > $@
> +
> +quiet_cmd_byconf = GENCONF $@
> + cmd_byconf = printf '\#define BYCONF_STR "CONF-%s"\n' '$(CONFIG_LOCALVERSION)' > $@
> +
> +# Regenerated when its input file changes.
> +$(obj)/byfile_gen.h: $(src)/byfile_gen.in FORCE
> + $(call if_changed,byfile)
> +
> +# No input file: regenerated only when its command line changes, which here
> +# means when CONFIG_LOCALVERSION changes. No file is touched.
> +$(obj)/byconf_gen.h: FORCE
> + $(call if_changed,byconf)
> +
> +targets += byfile_gen.h byconf_gen.h
> +
> +# The anchors declare the dependency. That is what generates the headers on
> +# a clean build: fixdep only records a header once the object has compiled
> +# successfully, so on a first build there is no .cmd file to rely on. The
> +# victims include the same headers without declaring them, so the only
> +# record of that edge is the deps_ list in their .cmd files.
> +$(obj)/byfile_anchor.o: $(obj)/byfile_gen.h
> +$(obj)/byconf_anchor.o: $(obj)/byconf_gen.h
> +
> +CFLAGS_byfile_anchor.o += -I$(obj)
> +CFLAGS_byfile_victim.o += -I$(obj)
> +CFLAGS_byconf_anchor.o += -I$(obj)
> +CFLAGS_byconf_victim.o += -I$(obj)
> diff --git a/lib/byconf_anchor.c b/lib/byconf_anchor.c
> new file mode 100644
> index 0000000000000..8035eaa352a3b
> --- /dev/null
> +++ b/lib/byconf_anchor.c
> @@ -0,0 +1,3 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include "byconf_gen.h"
> +const char byconf_anchor_marker[] = BYCONF_STR;
> diff --git a/lib/byconf_victim.c b/lib/byconf_victim.c
> new file mode 100644
> index 0000000000000..285a8de8bdf6e
> --- /dev/null
> +++ b/lib/byconf_victim.c
> @@ -0,0 +1,3 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include "byconf_gen.h"
> +const char byconf_victim_marker[] = BYCONF_STR;
> diff --git a/lib/byfile_anchor.c b/lib/byfile_anchor.c
> new file mode 100644
> index 0000000000000..9ea0b8ad55963
> --- /dev/null
> +++ b/lib/byfile_anchor.c
> @@ -0,0 +1,3 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include "byfile_gen.h"
> +const char byfile_anchor_marker[] = BYFILE_STR;
> diff --git a/lib/byfile_gen.in b/lib/byfile_gen.in
> new file mode 100644
> index 0000000000000..7da9e5e0cd83c
> --- /dev/null
> +++ b/lib/byfile_gen.in
> @@ -0,0 +1 @@
> +FROMFILE-one
> diff --git a/lib/byfile_victim.c b/lib/byfile_victim.c
> new file mode 100644
> index 0000000000000..763c5ef8f1514
> --- /dev/null
> +++ b/lib/byfile_victim.c
> @@ -0,0 +1,3 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include "byfile_gen.h"
> +const char byfile_victim_marker[] = BYFILE_STR;
>
>
> --
> Kees Cook
--
Cheers, Lorenzo
next prev parent reply other threads:[~2026-09-19 17:03 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 16:06 [PATCH v3 00/20] kbuild: significantly speed up kernel builds Lorenzo Stoakes (ARM)
2026-09-17 16:06 ` [PATCH v3 01/20] kbuild: do not allocate .modinfo in vmlinux Lorenzo Stoakes (ARM)
2026-09-17 16:52 ` Kees Cook
2026-09-17 17:41 ` Lorenzo Stoakes (ARM)
2026-09-18 0:51 ` Nathan Chancellor
2026-09-18 17:09 ` Nicolas Schier
2026-09-18 21:44 ` Nathan Chancellor
2026-09-19 14:39 ` Lorenzo Stoakes (ARM)
2026-09-17 17:05 ` Kees Cook
2026-09-17 17:39 ` Lorenzo Stoakes (ARM)
2026-09-17 16:06 ` [PATCH v3 02/20] kallsyms: index symbols by token to speed up table compression Lorenzo Stoakes (ARM)
2026-09-17 17:27 ` Kees Cook
2026-09-17 17:45 ` Lorenzo Stoakes (ARM)
2026-09-17 16:06 ` [PATCH v3 03/20] kallsyms: output binary data to speed output and kallsyms assembly Lorenzo Stoakes (ARM)
2026-09-17 17:36 ` Kees Cook
2026-09-17 16:06 ` [PATCH v3 04/20] kbuild: do not sort nm output where the order is irrelevant Lorenzo Stoakes (ARM)
2026-09-17 17:38 ` Kees Cook
2026-09-18 19:14 ` Nicolas Schier
2026-09-17 16:06 ` [PATCH v3 05/20] kbuild: only emit vmlinux relocations when required Lorenzo Stoakes (ARM)
2026-09-17 17:41 ` Kees Cook
2026-09-17 17:48 ` Lorenzo Stoakes (ARM)
2026-09-18 19:27 ` Nicolas Schier
2026-09-17 16:06 ` [PATCH v3 06/20] elf-parse: add section flags, symbol binding and a read-only mapping Lorenzo Stoakes (ARM)
2026-09-17 17:44 ` Kees Cook
2026-09-17 16:06 ` [PATCH v3 07/20] kallsyms: reimplement mksysmap in C Lorenzo Stoakes (ARM)
2026-09-17 18:07 ` Kees Cook
2026-09-19 16:24 ` Lorenzo Stoakes (ARM)
2026-09-19 16:25 ` Lorenzo Stoakes (ARM)
2026-09-17 16:06 ` [PATCH v3 08/20] kbuild: cache list, composite object state per object Lorenzo Stoakes (ARM)
2026-09-17 18:11 ` Kees Cook
2026-09-18 19:51 ` Nicolas Schier
2026-09-19 14:48 ` Lorenzo Stoakes (ARM)
2026-09-17 16:06 ` [PATCH v3 09/20] kbuild: implement and use depcheck to check dependency timestamps Lorenzo Stoakes (ARM)
2026-09-17 18:42 ` Kees Cook
2026-09-17 20:59 ` Kees Cook
2026-09-19 17:02 ` Lorenzo Stoakes (ARM) [this message]
2026-09-20 3:46 ` Kees Cook
2026-09-19 16:57 ` Lorenzo Stoakes (ARM)
2026-09-19 17:06 ` Lorenzo Stoakes (ARM)
2026-09-20 3:48 ` Kees Cook
2026-09-17 16:06 ` [PATCH v3 10/20] kbuild: move the toolchain checks into init/Kconfig.toolchain Lorenzo Stoakes (ARM)
2026-09-17 18:53 ` Kees Cook
2026-09-18 1:07 ` Nathan Chancellor
2026-09-18 14:35 ` Lorenzo Stoakes (ARM)
2026-09-18 19:54 ` Nicolas Schier
2026-09-18 21:12 ` Nathan Chancellor
2026-09-19 14:45 ` Lorenzo Stoakes (ARM)
2026-09-17 16:06 ` [PATCH v3 11/20] kbuild: avoid re-running compiler and linker probes Lorenzo Stoakes (ARM)
2026-09-17 19:26 ` Kees Cook
2026-09-18 1:21 ` Nathan Chancellor
2026-09-18 4:44 ` Kees Cook
2026-09-18 5:40 ` Nathan Chancellor
2026-09-19 17:31 ` Lorenzo Stoakes (ARM)
2026-09-17 16:06 ` [PATCH v3 12/20] modpost: cache section relocation mismatch state Lorenzo Stoakes (ARM)
2026-09-17 16:06 ` [PATCH v3 13/20] modpost: emit module descriptors as assembly Lorenzo Stoakes (ARM)
2026-09-17 16:06 ` [PATCH v3 14/20] kbuild: batch module finalisation Lorenzo Stoakes (ARM)
2026-09-17 17:01 ` Kees Cook
2026-09-17 16:06 ` [PATCH v3 15/20] objtool: cache relocations, do less work, eliminate relocation hash Lorenzo Stoakes (ARM)
2026-09-17 16:06 ` [PATCH v3 16/20] objtool: size the instruction hash to the text Lorenzo Stoakes (ARM)
2026-09-17 16:06 ` [PATCH v3 17/20] objtool: decode instructions and resolve branch targets in parallel Lorenzo Stoakes (ARM)
2026-09-17 16:06 ` [PATCH v3 18/20] rust: make exports.o depend on the headers generated for it Lorenzo Stoakes (ARM)
2026-09-17 16:06 ` [PATCH v3 19/20] kbuild: build rust crates in parallel with the rest of the build Lorenzo Stoakes (ARM)
2026-09-17 16:06 ` [PATCH v3 20/20] kbuild: compress the kernel with pigz if available Lorenzo Stoakes (ARM)
2026-09-17 16:58 ` Kees Cook
2026-09-19 17:43 ` Lorenzo Stoakes (ARM)
2026-09-18 14:27 ` Manuel Ebner
2026-09-19 17:42 ` Lorenzo Stoakes (ARM)
2026-09-17 17:15 ` [PATCH v3 00/20] kbuild: significantly speed up kernel builds Linus Torvalds
2026-09-17 17:36 ` Lorenzo Stoakes (ARM)
2026-09-17 19:42 ` Lorenzo Stoakes (ARM)
2026-09-17 20:02 ` Nick Desaulniers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aq6_JcIy6gOsN4oa@gremlin \
--to=ljs@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=alex@ghiti.fr \
--cc=aliceryhl@google.com \
--cc=aou@eecs.berkeley.edu \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=axboe@kernel.dk \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=dave.hansen@linux.intel.com \
--cc=gary@garyguo.net \
--cc=gustavoars@kernel.org \
--cc=hpa@zytor.com \
--cc=ilias.apalodimas@linaro.org \
--cc=jpoimboe@kernel.org \
--cc=justinstitt@google.com \
--cc=kees@kernel.org \
--cc=legion@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=llvm@lists.linux.dev \
--cc=lossin@kernel.org \
--cc=mark.rutland@arm.com \
--cc=masahiroy@kernel.org \
--cc=mingo@redhat.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=nsc@kernel.org \
--cc=ojeda@kernel.org \
--cc=palmer@dabbelt.com \
--cc=peterz@infradead.org \
--cc=pjw@kernel.org \
--cc=rdunlap@infradead.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tamird@kernel.org \
--cc=tglx@kernel.org \
--cc=tmgross@umich.edu \
--cc=torvalds@linux-foundation.org \
--cc=will@kernel.org \
--cc=work@onurozkan.dev \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®