Re: [PATCH v4 11/27] s390: Use arm64 headers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Double `$(objtree)` prefix in `arm64-dst` causes out-of-tree builds to fail.
- [Medium] The `sysreg-defs.h` target will be unnecessarily rebuilt on every `make` invocation during out-of-tree builds due to a `targets` array mismatch.
- [Low] The include guard regex in `copy-arm64h-full.awk` fails to match standard ARM64 KVM headers that contain numbers.
- [Low] The commit message incorrectly states that included headers are rewritten to `#include <arm64/asm/...>`, but the implementation correctly rewrites them to `#include <arm64/...>` instead.
--

commit 622a9e9498e4f7fc1aed85088dd8016c40e7fc8b
Author: Steffen Eiden <seiden@linux.ibm.com>

s390: Use arm64 headers

Introduce a flexible system for sharing ARM64 headers with s390 KVM.
Selected arm64 headers or snippet of headers will be reachable by s390
code through asm/header.h.

> Transform copied includes by replacing '#include <asm/...>' with
> '#include <arm64/asm/...>' and similar for uapi headers to ensure
> correct path resolution on s390 and allow for a clear separation of s390

[Severity: Low]
This isn't a bug, but the commit message states the headers are rewritten to
'#include <arm64/asm/...>', while the awk scripts in this patch correctly
rewrite them to '#include <arm64/...>' without the 'asm/' component.

> diff --git a/arch/s390/tools/Makefile b/arch/s390/tools/Makefile
> index f2862364fb422..bd2a00d5ce2c9 100644
> --- a/arch/s390/tools/Makefile
> +++ b/arch/s390/tools/Makefile
[ ... ]
> @@ -3,8 +3,13 @@
>  # Makefile for s390 specific build tools
>  #
>  
> +include $(srctree)/arch/s390/tools/Makefile.arm64h
> +
>  kapi := arch/$(ARCH)/include/generated/asm
>  kapi-hdrs-y := $(kapi)/facility-defs.h $(kapi)/dis-defs.h
> +kapi-hdrs-$(CONFIG_KVM_ARM64) += $(ARM64_TARGETS)
> +
> +targets += $(addprefix ../../../,$(kapi-hdrs-y))

[Severity: Medium]
Will this unnecessarily rebuild sysreg-defs.h on every make invocation during
out-of-tree builds?

In Makefile.arm64h, sysreg-defs.h is added to ARM64_TARGETS using an absolute
path because arm64api includes $(objtree).

Then here, it gets appended to the targets array with a relative directory
traversal using $(addprefix ../../../,$(kapi-hdrs-y)).

Prepending a relative traversal to an absolute path
(like ../../..//build_dir/...) creates a malformed path. This prevents Kbuild
from locating the .cmd file and breaks the if_changed cache.

> diff --git a/arch/s390/tools/Makefile.arm64h b/arch/s390/tools/Makefile.arm64h
> new file mode 100644
> index 0000000000000..0b32c124707d9
> --- /dev/null
> +++ b/arch/s390/tools/Makefile.arm64h
> @@ -0,0 +1,58 @@
[ ... ]
> +arm64api := $(objtree)/arch/$(ARCH)/include/generated/arm64
> +arm64uapi := $(objtree)/arch/$(ARCH)/include/generated/uapi/arm64
[ ... ]
> +arm64-src = $(srctree)/arch/arm64/include/$(if $(filter uapi,$(call arm64-type,$(1))),uapi/)asm/$(call arm64-src-base,$(1))
> +arm64-dst = $(objtree)/$(if $(filter uapi,$(call arm64-type,$(1))),$(arm64uapi),$(arm64api))/$(call arm64-base,$(1))

[Severity: High]
Does this double prefix of $(objtree) break out-of-tree builds?

Since arm64api and arm64uapi are defined above with the $(objtree) prefix
already, arm64-dst prepends $(objtree)/ to them again.

This causes paths to resolve to a nested build_dir/build_dir/... structure
during out-of-tree compilation.

> diff --git a/arch/s390/tools/copy-arm64h-full.awk b/arch/s390/tools/copy-arm64h-full.awk
> new file mode 100644
> index 0000000000000..a9b85b347f780
> --- /dev/null
> +++ b/arch/s390/tools/copy-arm64h-full.awk
> @@ -0,0 +1,43 @@
[ ... ]
> +# Find and process the include guard in the first few lines
> +NR <= max_guard_line && !guard_found && /^#ifndef [A-Z_]+$/ {

[Severity: Low]
Does this strict regex fail to match include guards containing numbers?

For standard ARM64 KVM headers that contain numbers in their guards
(e.g., __ARM64_KVM_ARM_H__), this fails to match.

This silently omits the 'This header was copied from...' preamble in the
generated files.

> +	guard_name = $2
> +	guard_found = 1
> +	print "/* This header was copied from " srcfile " */"

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706085229.979525-1-seiden@linux.ibm.com?part=11