Re: [PATCH v2 20/21] kbuild: build rust crates in parallel with the rest of the build

[Kees Cook]

On Mon, Sep 14, 2026 at 10:22:19AM +0100, Lorenzo Stoakes (ARM) wrote:
> Care is taken to ensure that external rust modules can still be built
> against the tree - make modules_prepare ... (where ... are other goals)
> will build rust/ first.
> [...]
>  prepare: prepare0
>  ifdef CONFIG_RUST
>  	+$(Q)$(CONFIG_SHELL) $(srctree)/scripts/rust_is_available.sh
> -	$(Q)$(MAKE) $(build)=rust
>  endif
>  
>  PHONY += remove-stale-files
> @@ -1760,6 +1763,12 @@ modules: modules_prepare
>  # Target to prepare building external modules
>  modules_prepare: prepare
>  	$(Q)$(MAKE) $(build)=scripts scripts/module.lds
> +ifdef CONFIG_RUST
> +# Ensure rust/ is built before any external rust module which will rely upon it.
> +ifneq ($(filter modules_prepare,$(MAKECMDGOALS)),)
> +	$(Q)$(MAKE) $(build)=rust
> +endif
> +endif

As far as I can see, nothing orders this recipe against the tree build,
which also descends into rust/ through "obj-$(CONFIG_RUST) += rust/"
in Kbuild, while $(build-dir) only depends on prepare. Before this
patch that was fine, because prepare had already built rust/ by the
time either of them ran. Now "make -jN modules_prepare all" can have
two make processes building rust/ at the same time, and so can
"make -jN rustdoc all" or "make -jN rusttest all", whose recipes also
run "$(MAKE) $(build)=rust". That means two rustc runs writing the same
objects in rust/ ...

> +# Rust code elsewhere in the tree depends upon rust/.
> +ifdef CONFIG_RUST
> +$(KBUILD_RUST_DIRS): | rust
> +endif
> [...]
> +export KBUILD_RUST_DIRS := drivers lib mm samples

Doesn't this make all of drivers/, lib/, mm/ and samples/ wait for rust/?
That's a lot of stall: drivers/ is most of the tree. I think then a
CONFIG_RUST build has most of its C work waiting on the rust chain;
only the other top-level directories start early? This didn't create new
build delays for those configurations?

-- 
Kees Cook