Linux Perf Users
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ian Rogers" <irogers@google.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v1] perf tests: Improvements to build-test performance
Date: Wed, 02 Sep 2026 15:40:40 +0000	[thread overview]
Message-ID: <20260902154041.5F69C1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260902153135.2067365-1-irogers@google.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The `out` target explicitly passes `-j$(cores)` to a sub-make, breaking GNU Make's native jobserver inheritance and triggering an unbounded fork bomb if `cores` is undefined.
- [Medium] Removing `$(call clean)` from `$(run_O)` causes out-of-tree builds to execute on a dirty source tree when run sequentially after in-tree builds.
--

commit 169a507e0cde997201a5b5a2dfdbe4652f1a9fa0
Author: Ian Rogers <irogers@google.com>

perf tests: Improvements to build-test performance

This commit aims to improve build-test performance by using $(MAKE) to ensure
GNU Make jobserver file descriptors are inherited by nested builds. It removes
sequential bottlenecks like $(call clean) from isolated tmp directories and
wraps the out target list in a parallel sub-make call.

> diff --git a/tools/perf/tests/make b/tools/perf/tests/make
> index d2c2f526e1db0..4f14c6b72416a 100644
> --- a/tools/perf/tests/make
> +++ b/tools/perf/tests/make
> @@ -339,7 +339,6 @@ make_static:
>  	rm -rf $@ $$TMP_DEST || (cat $@ ; false)
>  
>  $(run_O):
> -	$(call clean)

[Severity: Medium]
Does removing this clean step cause out-of-tree builds to execute on a dirty
source tree when run sequentially?

When the default all target is executed:

all: $(run) $(run_O) tarpkg make_kernelsrc make_kernelsrc_tools

The $(run) in-tree builds execute first and leave the source tree dirty.
Since $(run_O) no longer calls $(call clean) before starting, it appears
the first out-of-tree build begins on that dirty source tree, breaking
build isolation.

>  	@TMP_O=$$(mktemp -d); \
>  	TMP_DEST=$$(mktemp -d); \
>  	cmd="cd $(PERF) && $(MAKE_F) $($(patsubst %_O,%,$@)) $(PARALLEL_OPT) O=$$TMP_O DESTDIR=$$TMP_DEST"; \

[ ... ]

> @@ -383,20 +382,21 @@ all: $(run) $(run_O) tarpkg make_kernelsrc make_kernelsrc_tools
>  	@echo OK
>  	@rm -f $(FEATURES_DUMP_FILE) $(FEATURES_DUMP_FILE_STATIC)
>  
> -out: $(run_O)
> +out: $(FEATURES_DUMP_FILE) $(FEATURES_DUMP_FILE_STATIC)
> +	@$(MAKE) -f tests/make $(run_O) PARALLEL_OPT= -j$(cores)

[Severity: High]
Does passing -j$(cores) here break native jobserver inheritance and risk an
unbounded fork bomb?

If a developer runs the out target directly without setting cores, the
-j$(cores) flag expands to -j without an integer. This instructs GNU Make
to spawn unlimited jobs, which is then inherited by all $(run_O) sub-makes.

Additionally, even when cores is defined, passing it explicitly to $(MAKE)
overrides any --jobserver-auth tokens passed from a parent make, breaking
the jobserver inheritance this patch aims to fix.

>  	@echo OK
>  	@rm -f $(FEATURES_DUMP_FILE) $(FEATURES_DUMP_FILE_STATIC)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902153135.2067365-1-irogers@google.com?part=1

  reply	other threads:[~2026-09-02 15:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 15:31 [PATCH v1] perf tests: Improvements to build-test performance Ian Rogers
2026-09-02 15:40 ` sashiko-bot [this message]
2026-09-03  4:56 ` [PATCH v2] " Ian Rogers
2026-09-03  5: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=20260902154041.5F69C1F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=irogers@google.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=sashiko-reviews@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