public inbox for linux-perf-users@vger.kernel.org
 help / color / mirror / Atom feed
From: cp0613@linux.alibaba.com
To: peterz@infradead.org, mingo@redhat.com, acme@kernel.org,
	namhyung@kernel.org, irogers@google.com, guoren@kernel.org
Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	Chen Pei <cp0613@linux.alibaba.com>
Subject: [PATCH] perf build: Avoid argument list too long in orphan pruning
Date: Fri, 13 Mar 2026 15:24:31 +0800	[thread overview]
Message-ID: <20260313072431.584-1-cp0613@linux.alibaba.com> (raw)

From: Chen Pei <cp0613@linux.alibaba.com>

When the output directory contains a large number of orphaned files with
deep file paths, directly passing the entire ORPHAN_FILES list to the
execve command will exceed the system's parameter length limit (it should
be MAX_ARG_STRLEN), causing "argument list too long" error during build.
See below:

  make[6]: execvp: /bin/sh: Argument list too long
  make[6]: *** [pmu-events/Build:217: prune_orphans] Error 127
  make[6]: *** Waiting for unfinished jobs....

Fix this by using GNU Make's $(file ...) function to write the orphan file
list to a temporary file, then use xargs to read from the file and remove
the orphan files. The temporary file is deleted after pruning completes.

This method avoids the argument length limitation since $(file ...) writes
directly without spawning a shell process with command-line arguments.

Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
---
 tools/perf/pmu-events/Build | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/perf/pmu-events/Build b/tools/perf/pmu-events/Build
index 63c65788d442..ec5bf89ddfe1 100644
--- a/tools/perf/pmu-events/Build
+++ b/tools/perf/pmu-events/Build
@@ -209,12 +209,17 @@ endif
 ifneq ($(strip $(ORPHAN_FILES)),)
 .PHONY: prune_orphans
 
+# Store ORPHAN_FILES in a file to avoid argument list too long errors
+ORPHAN_LIST_FILE := $(OUTPUT)pmu-events/.orphan_list
+$(file >$(ORPHAN_LIST_FILE),$(ORPHAN_FILES))
+
 # Message for $(call echo-cmd,rm). Generally cleaning files isn't part
 # of a build step.
 quiet_cmd_rm  = RM      $^
 
-prune_orphans: $(ORPHAN_FILES)
-	$(Q)$(call echo-cmd,rm)rm -f $^
+prune_orphans: $(ORPHAN_LIST_FILE)
+	$(Q)$(call echo-cmd,rm)cat $^ | xargs rm -f
+	$(Q)rm -f $(ORPHAN_LIST_FILE)
 
 JEVENTS_DEPS += prune_orphans
 endif
-- 
2.50.1


             reply	other threads:[~2026-03-13  7:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-13  7:24 cp0613 [this message]
2026-03-13  8:36 ` [PATCH] perf build: Avoid argument list too long in orphan pruning cp0613
2026-03-13 15:47   ` Ian Rogers
2026-03-17  1:44     ` cp0613

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=20260313072431.584-1-cp0613@linux.alibaba.com \
    --to=cp0613@linux.alibaba.com \
    --cc=acme@kernel.org \
    --cc=guoren@kernel.org \
    --cc=irogers@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.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