Linux Perf Users
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Florian Fainelli" <florian.fainelli@broadcom.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH stable 7.0] perf build: fix "argument list too long" in second location
Date: Thu, 14 May 2026 11:44:25 +0000	[thread overview]
Message-ID: <20260514114426.33919C2BCB3@smtp.kernel.org> (raw)
In-Reply-To: <20260513234639.128528-1-florian.fainelli@broadcom.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The fix for the 'Argument list too long' build error is incomplete. It reduces the shell command length by removing the file list from the 'RM' output, but still embeds the full file list via `echo "$^"` within the shell command executed by Make. This means the build will still fail with the exact same E2BIG error if the number of files increases further or if the build directory has a long absolute path.
--

commit 3997e5cf292c966edf5b226f773ec398849158ff
Author: Markus Mayer <mmayer@broadcom.com>

perf build: fix "argument list too long" in second location

This commit addresses an "argument list too long" build error by replacing
the explicit file list in quiet_cmd_rm with a file count. It also moves a
comment about xargs above the rule.

> diff --git a/tools/perf/pmu-events/Build b/tools/perf/pmu-events/Build
> index dc5f94862a3bc..dc1df2d57ddc1 100644
> --- a/tools/perf/pmu-events/Build
> +++ b/tools/perf/pmu-events/Build
> @@ -211,10 +211,10 @@ ifneq ($(strip $(ORPHAN_FILES)),)
>  
>  # Message for $(call echo-cmd,rm). Generally cleaning files isn't part
>  # of a build step.
> -quiet_cmd_rm  = RM      $^
> +quiet_cmd_rm = RM      ...$(words $^) orphan file(s)...
>  
> +# The list of files can be long. Use xargs to prevent issues.
>  prune_orphans: $(ORPHAN_FILES)
> -	# The list of files can be long. Use xargs to prevent issues.
>  	$(Q)$(call echo-cmd,rm)echo "$^" | xargs rm -f

Is the fix for the argument list too long error complete here?

When Make executes a recipe containing shell operators (like |), it spawns
/bin/sh -c "<recipe>". The entire recipe string is passed as argv[2] to
the shell, which is subject to the Linux MAX_ARG_STRLEN limit.

By removing $^ from quiet_cmd_rm, this change reduces the size of the
recipe string, which might temporarily drop it below the limit for the
current number of files.

However, echo "$^" | xargs rm -f still embeds the full file list directly
into the shell argument. If the path lengths or file count grow further,
couldn't this still exceed MAX_ARG_STRLEN and break the build?

Would it be more robust to bypass the shell argument limits entirely, for
instance by using Make's $(file ...) function to write the list directly
to a file?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513234639.128528-1-florian.fainelli@broadcom.com?part=1

      reply	other threads:[~2026-05-14 11:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-13 23:46 [PATCH stable 7.0] perf build: fix "argument list too long" in second location Florian Fainelli
2026-05-14 11:44 ` sashiko-bot [this message]

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=20260514114426.33919C2BCB3@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=florian.fainelli@broadcom.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