Re: [PATCH 41/58] objtool/klp: Add test for kCFI prefix symbols and traps

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The compiler may optimize away the indirect call in `target()`, which would eliminate the expected `.kcfi_traps` entry and break the test on newer or more aggressive Clang versions.
--

commit ab08ca5f9689c4205bf1341ad94b14e2747fd94b
Author: Song Liu <song@kernel.org>

objtool/klp: Add test for kCFI prefix symbols and traps

This commit adds a test case to verify that the __cfi_<func> prefix symbol
and its .kcfi_traps entry are correctly handled and carried into a patch for
kCFI-enabled builds.

> diff --git a/tools/objtool/tests/x86/fixtures/kcfi.c b/tools/objtool/tests/x86/fixtures/kcfi.c
> new file mode 100644
> index 0000000000000..52cbb0fe6df2a
> --- /dev/null
> +++ b/tools/objtool/tests/x86/fixtures/kcfi.c

[ ... ]

> +int (*pick(int x))(int)
> +{
> +	return (x & 1) ? impl_a : impl_b;
> +}

[Severity: Low]
Will the compiler aggressively inline this function into target()?

Lacking a noinline attribute, this function can be fully inlined, exposing the
function pointers for devirtualization.

> +
> +int target(int x)
> +{
> +	int (*fn)(int arg) = pick(x);
> +
> +#ifdef PATCHED
> +	return fn(x) + 2;

[Severity: Low]
Could aggressive compiler optimizations devirtualize this indirect call?

The indirect call fn(x) relies on pick() and its targets not being inlined to
remain an indirect call in the final object code. If devirtualized, the
expected .kcfi_traps entry would be removed, potentially causing the test to
spuriously fail on newer or more aggressive Clang versions.

> +#else
> +	return fn(x) + 1;
> +#endif
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260911185031.1534046-1-song@kernel.org?part=41