> diff --git a/scripts/Makefile b/scripts/Makefile > index 3434a82a119f0..366c6a35141a6 100644 > --- a/scripts/Makefile > +++ b/scripts/Makefile > @@ -51,6 +51,9 @@ endif > > ifdef CONFIG_BUILDTIME_MCOUNT_SORT > HOSTCFLAGS_sorttable.o += -DMCOUNT_SORT_ENABLED > +ifneq ($(filter-out 0,$(CONFIG_ARM64_FUNCTION_PREFIX_NOPS)),) > +HOSTCFLAGS_sorttable.o += -DFUNCTION_PREFIX_BYTES=$(shell expr 4 \* > $(CONFIG_ARM64_FUNCTION_PREFIX_NOPS)) > +endif > endif
This isn't a bug, but would it be worth letting a configured 0 through here (or noting why it deliberately keeps the historical 8-byte tolerance), so the block doesn't read as honouring a value it actually filters out? As written, when CONFIG_ARM64_FUNCTION_PREFIX_NOPS is set to 0, the guard treats it the same as the symbol being absent, so both fall back to sorttable.c's built-in 8. This is behaviour-preserving today and avoids passing an empty value to expr, but once the symbol lands with a default of 0 for the non-CALL_OPS case, the one configured value that differs from the legacy constant is the one the guard discards. [ ... ] --- AI reviewed your patch. Please fix the bug or email reply why it's not a bug. See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md CI run summary: https://github.com/kernel-patches/bpf/actions/runs/33826319138
