From: Kees Cook kees@kernel.org
[ Upstream commit 65c430906efffee9bd7551d474f01a6b1197df90 ]
GCC appears to have kind of fragile inlining heuristics, in the sense that it can change whether or not it inlines something based on optimizations. It looks like the kcov instrumentation being added (or in this case, removed) from a function changes the optimization results, and some functions marked "inline" are _not_ inlined. In that case, we end up with __init code calling a function not marked __init, and we get the build warnings I'm trying to eliminate in the coming patch that adds __no_sanitize_coverage to __init functions:
WARNING: modpost: vmlinux: section mismatch in reference: acpi_get_enable_method+0x1c (section: .text.unlikely) -> acpi_psci_present (section: .init.text)
This problem is somewhat fragile (though using either __always_inline or __init will deterministically solve it), but we've tripped over this before with GCC and the solution has usually been to just use __always_inline and move on.
For arm64 this requires forcing one ACPI function to be inlined with __always_inline.
Link: https://lore.kernel.org/r/20250724055029.3623499-1-kees@kernel.org Signed-off-by: Kees Cook kees@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
Based on my analysis, here is my determination:
**Backport Status: YES**
This commit should be backported to stable kernel trees for the following reasons:
1. **Fixes a real build warning/bug**: The commit addresses section mismatch warnings that occur when GCC's inlining heuristics change due to KCOV instrumentation. These warnings indicate potential runtime issues where __init code (which gets discarded after boot) calls non-__init functions, which could lead to crashes if those functions are called after the __init sections are freed.
2. **Minimal and contained change**: The fix is extremely simple - it only changes one function declaration from `static inline` to `static __always_inline` in arch/arm64/include/asm/acpi.h:153. This is a minimal change with very low risk.
4. **Prevents build regressions**: Without this fix, enabling KCOV instrumentation could cause build failures or warnings in stable kernels, which would be a regression for users who need to use KCOV for testing.
5. **Well-understood issue**: The commit message clearly explains the root cause - GCC's fragile inlining heuristics that change based on optimizations/instrumentation. The solution (__always_inline) is a well-established pattern in the kernel for forcing inlining.
6. **No functional change**: The change only affects compilation behavior by forcing inlining. The actual runtime behavior remains identical - `acpi_get_enable_method()` still calls `acpi_psci_present()` (marked __init) and returns the same values.
The specific code change shows `acpi_get_enable_method()` being changed from `static inline` to `static __always_inline`. This function calls `acpi_psci_present()`, which is marked `__init` (as seen in arch/arm64/kernel/acpi.c:110). Without forced inlining, GCC might not inline `acpi_get_enable_method()`, resulting in non-__init code calling __init code, triggering the section mismatch warning.
This is exactly the type of targeted, low-risk fix that stable trees are meant to include.
arch/arm64/include/asm/acpi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h index 702587fda70c..8cbbd08cc8c5 100644 --- a/arch/arm64/include/asm/acpi.h +++ b/arch/arm64/include/asm/acpi.h @@ -128,7 +128,7 @@ acpi_set_mailbox_entry(int cpu, struct acpi_madt_generic_interrupt *processor) {} #endif
-static inline const char *acpi_get_enable_method(int cpu) +static __always_inline const char *acpi_get_enable_method(int cpu) { if (acpi_psci_present()) return "psci";