[PATCH] tools/resolve_btfids: fix OUTPUT leakage from kselftest causing corrupted build paths

[PATCH] tools/resolve_btfids: fix OUTPUT leakage from kselftest causing corrupted build paths

[Jiangshan Yi]

When building kselftest-all, the kselftest Makefile passes OUTPUT as a
command-line variable to each test directory:

  tools/testing/selftests/Makefile:
    $(MAKE) OUTPUT=$$BUILD/$$TARGET -C $$TARGET

GNU Make automatically exports command-line variables to all sub-makes.
This OUTPUT propagates through the entire build chain:

  kselftest/mm (OUTPUT=.../selftests/mm)
    -> gen_mods_dir -> page_frag (kernel module build)
      -> tools/bpf/resolve_btfids (host tool dependency)

The resolve_btfids Makefile uses a conditional assignment:

  OUTPUT ?= $(srctree)/tools/bpf/resolve_btfids/

However, ?= cannot override a variable inherited from a parent build's
command line or environment.  The inherited OUTPUT points to the wrong
directory (the mm selftest directory) and lacks a trailing slash.

The tools/build Makefile.build system concatenates $(OUTPUT) with
filenames without a separating slash in its pattern rules:

  $(OUTPUT)%.o: %.c FORCE

When OUTPUT lacks a trailing '/', this produces corrupted paths such
as ".../selftests/mmmain.o" instead of ".../selftests/mm/main.o".
Meanwhile, the resolve_btfids Makefile itself uses $(OUTPUT)/filename
(with an explicit slash), so the HOSTLD step produces the file at a
different path than where the LINK step looks for it:

  HOSTLD produces: .../selftests/mmresolve_btfids-in.o  (no slash)
  LINK looks for:  .../selftests/mm/resolve_btfids-in.o  (with slash)

This results in a linker error:

  ld: cannot find .../resolve_btfids-in.o: No such file or directory

Fix this by checking the origin of OUTPUT.  When it is "command line"
or "environment" (indicating leakage from a parent build such as
kselftest), use 'override' to reset it to the correct directory.  When
built normally via the kernel build system, OUTPUT is set by
scripts/Makefile.include with origin "file" from the O= parameter,
which is correct and remains unaffected.

The fix can be reproduced and verified with:

  make -C tools/bpf/resolve_btfids clean
  # Before fix: fails with corrupted paths
  make OUTPUT=/path/to/selftests/mm -C tools/bpf/resolve_btfids
  # After fix: succeeds, artifacts in resolve_btfids directory

  # Also test environment variable leakage:
  OUTPUT=/path/to/selftests/mm make -C tools/bpf/resolve_btfids

Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn>
---
 tools/bpf/resolve_btfids/Makefile | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/tools/bpf/resolve_btfids/Makefile b/tools/bpf/resolve_btfids/Makefile
index 7672208f65e4..eee88c73fd7a 100644
--- a/tools/bpf/resolve_btfids/Makefile
+++ b/tools/bpf/resolve_btfids/Makefile
@@ -26,6 +26,22 @@ HOSTAR  ?= ar
 HOSTPKG_CONFIG ?= pkg-config
 CROSS_COMPILE =
 
+# If OUTPUT was inherited from a parent build's command line (e.g. from
+# kselftest), it points to the wrong directory and may lack a trailing
+# slash.  The tools/build Makefile.build concatenates $(OUTPUT) with
+# filenames without a separating slash ($(OUTPUT)%.o), so a missing
+# trailing '/' produces corrupted paths such as "mmmain.o" instead of
+# "mm/main.o", and the linker cannot find resolve_btfids-in.o.
+#
+# When built via the kernel build system, OUTPUT is set by
+# scripts/Makefile.include (origin "file") from the O= parameter, which
+# is correct.  Only a command-line origin indicates leakage from a
+# parent build and needs to be reset.  Both "command line" and
+# "environment" origins indicate leakage; "file" (set by Makefile.include
+# from O=) and "undefined" are legitimate and must not be overridden.
+ifneq ($(filter command line environment,$(origin OUTPUT)),)
+override OUTPUT := $(srctree)/tools/bpf/resolve_btfids/
+endif
 OUTPUT ?= $(srctree)/tools/bpf/resolve_btfids/
 
 LIBBPF_SRC := $(srctree)/tools/lib/bpf/
-- 
2.25.1

Re: [PATCH] tools/resolve_btfids: fix OUTPUT leakage from kselftest causing corrupted build paths

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch forcibly overrides the `OUTPUT` variable to the source tree directory if its origin is `command line` or `environment`. This breaks intentional out-of-tree builds for kernel tools and selftests (such as BPF and HID) which explicitly pass an `OUTPUT=` path on the command line. By overriding the requested path, the build writes artifacts into the source tree instead of the expected output directory, violating read-only source tree configurations and causing the selftest builds to fail because the `resolve_btfids` binary is missing from the required location.
--

--- Patch [1]: [PATCH] tools/resolve_btfids: fix OUTPUT leakage from kselftest causing corrupted build paths ---
commit b49b49183f48428e27843ec3019b42192ca9ed12
Author: Jiangshan Yi <yijiangshan@kylinos.cn>

tools/resolve_btfids: fix OUTPUT leakage from kselftest causing corrupted build paths

This commit addresses corrupted build paths caused by the OUTPUT variable
leaking from parent makes like kselftest. It attempts to fix this by checking
if OUTPUT comes from the command line or environment, and if so, overrides
it back to the source tree directory.

> diff --git a/tools/bpf/resolve_btfids/Makefile b/tools/bpf/resolve_btfids/Makefile
> index 7672208f65e4b..eee88c73fd7a1 100644
> --- a/tools/bpf/resolve_btfids/Makefile
> +++ b/tools/bpf/resolve_btfids/Makefile
> @@ -26,6 +26,22 @@ HOSTAR  ?= ar
>  HOSTPKG_CONFIG ?= pkg-config
>  CROSS_COMPILE =
>  
> +# If OUTPUT was inherited from a parent build's command line (e.g. from
> +# kselftest), it points to the wrong directory and may lack a trailing
> +# slash.  The tools/build Makefile.build concatenates $(OUTPUT) with
> +# filenames without a separating slash ($(OUTPUT)%.o), so a missing
> +# trailing '/' produces corrupted paths such as "mmmain.o" instead of
> +# "mm/main.o", and the linker cannot find resolve_btfids-in.o.
> +#
> +# When built via the kernel build system, OUTPUT is set by
> +# scripts/Makefile.include (origin "file") from the O= parameter, which
> +# is correct.  Only a command-line origin indicates leakage from a
> +# parent build and needs to be reset.  Both "command line" and
> +# "environment" origins indicate leakage; "file" (set by Makefile.include
> +# from O=) and "undefined" are legitimate and must not be overridden.
> +ifneq ($(filter command line environment,$(origin OUTPUT)),)
> +override OUTPUT := $(srctree)/tools/bpf/resolve_btfids/
> +endif

[Severity: Low]
Does this override break intentional out-of-tree builds? 

When building BPF or HID selftests out-of-tree, the build system explicitly
passes an OUTPUT= path on the command line. Because the origin is evaluated as
"command line", this logic unconditionally overrides it, discarding the properly
requested out-of-tree path.

Won't this cause artifacts to be written directly into the source tree, violating
read-only source tree configurations and causing the build to fail when it looks
for the resolve_btfids binary in the expected output directory?

>  OUTPUT ?= $(srctree)/tools/bpf/resolve_btfids/
>  
>  LIBBPF_SRC := $(srctree)/tools/lib/bpf/

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260716085733.1761196-1-yijiangshan@kylinos.cn?part=1