From: sashiko-bot@kernel.org
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v5 11/14] module: update timestamp of modules.order after modules are built
Date: Tue, 05 May 2026 09:41:49 +0000 [thread overview]
Message-ID: <20260505094150.54432C2BCB9@smtp.kernel.org> (raw)
In-Reply-To: <20260505-module-hashes-v5-11-e174a5a49fce@weissschuh.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Touching `modules.order` in `Makefile.modfinal` causes unnecessary rebuilds of `Module.symvers` on subsequent `make` invocations.
--
commit c15348209a95736a85efe8f0905f610fb5def492
Author: Thomas Weißschuh <linux@weissschuh.net>
module: update timestamp of modules.order after modules are built
This commit ensures modules.order is always newer than the module .ko files
by touching it after modules are built, allowing other rules to use it as a
prerequisite.
> diff --git a/scripts/Makefile.modfinal b/scripts/Makefile.modfinal
> index b09040ccddd2b..44a382689a5aa 100644
> --- a/scripts/Makefile.modfinal
> +++ b/scripts/Makefile.modfinal
> @@ -66,6 +66,13 @@ endif
>
> targets += $(modules:%.o=%.ko) $(modules:%.o=%.mod.o) .module-common.o
>
> +# Update modules.order when a module is (re-)built.
> +# Allow using it as target dependency.
> +targets += modules.order
> +__modfinal: modules.order
> +modules.order: $(modules:%.o=%.ko)
> + @touch $@
Does this cause an unnecessary rebuild of Module.symvers on subsequent make
invocations?
In scripts/Makefile.modpost, Module.symvers depends on modules.order. During
a build, Makefile.modpost is executed strictly before Makefile.modfinal.
When a module is rebuilt, touching modules.order here updates its modification
time to be newer than the previously generated Module.symvers. On the next
make invocation, even without source changes, Makefile.modpost will see
modules.order as newer than Module.symvers.
Will this trigger modpost to execute unnecessarily, degrading incremental
build performance by forcing an extra settling build to reach a clean state?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260505-module-hashes-v5-0-e174a5a49fce@weissschuh.net?part=11
next prev parent reply other threads:[~2026-05-05 9:41 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 9:05 [PATCH v5 00/14] module: Introduce hash-based integrity checking Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 01/14] kbuild: generate module BTF based on vmlinux.unstripped Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 02/14] lockdown: Make the relationship to MODULE_SIG a dependency Thomas Weißschuh
2026-05-05 9:32 ` sashiko-bot
2026-05-05 12:27 ` Nicolas Bouchinet
2026-05-05 9:05 ` [PATCH v5 03/14] kbuild: rename the strip_relocs command Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 04/14] module: Drop pointless debugging message Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 05/14] module: Make mod_verify_sig() static Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 06/14] module: Switch load_info::len to size_t Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 07/14] module: Make module authentication usable without MODULE_SIG Thomas Weißschuh
2026-05-05 9:40 ` sashiko-bot
2026-05-05 9:05 ` [PATCH v5 08/14] module: Move authentication logic into dedicated new file Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 09/14] module: Move signature type check out of mod_check_sig() Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 10/14] module: Prepare for additional module authentication mechanisms Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 11/14] module: update timestamp of modules.order after modules are built Thomas Weißschuh
2026-05-05 9:41 ` sashiko-bot [this message]
2026-05-05 9:05 ` [PATCH v5 12/14] module: Introduce hash-based integrity checking Thomas Weißschuh
2026-05-05 9:49 ` sashiko-bot
2026-05-05 9:05 ` [PATCH v5 13/14] kbuild: move handling of module stripping to Makefile.lib Thomas Weißschuh
2026-05-05 9:35 ` sashiko-bot
2026-05-05 9:05 ` [PATCH v5 14/14] kbuild: make CONFIG_MODULE_HASHES compatible with module stripping Thomas Weißschuh
2026-05-05 10:04 ` sashiko-bot
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=20260505094150.54432C2BCB9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=sashiko@lists.linux.dev \
/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