Re: [RFC PATCH 04/20] compiler_types.h: Don't instrument __always_inline functions for coverage

[Sasha Levin]

On Wed, Oct 28, 2026 at 02:51:40PM +0100, Peter Zijlstra wrote:
>This is pretty vile. But also, since people were trying to use MC/DC for
>validation efforts and the like, how does this impact them? If I
>understand correctly their previous emails on the topic, this means they
>have to go manually audit every single __always_inline function.

Yes, the __always_inline helpers join noinstr code as something that
has to be justified separately rather than covered by tests. Steve's
answer to your noinstr question in 2024 [1] was that this is workable
as long as the number of distinct categories stays small, and this
adds one (556 functions and 445 MC/DC conditions for the config in the
changelog).

Chuck, Steve, does that match what you'd expect on your side?

>Still, I'm left wondering if these tools should be fixed. For instance,
>while the front-end emits this instrumentation, the backend could easily
>remove it again when it finds itself in the context of a noinstr
>function after inlining.

Yup, we should do that. Both GCC and Clang add the counters before
inlining and let always_inline win over the attribute mismatch, so
neither can do it today. We can look at improving them, but it's probably
outside of what this series can do.

On Wed, Oct 28, 2026 at 03:01:18PM +0100, Peter Zijlstra wrote:
>Ah, also, we have objtool's hack_noinstr :/ But sssh, don't tell Josh
>about that.

I looked at that. NOPing the gcov counter updates would be easy, as
they're all single locked instructions, but Clang's MC/DC bitmap
updates go through registers and would need dataflow analysis. It
would also only help x86, while gcov and noinstr are on arm64, riscv
and s390 too. So I'd rather keep this as the guarantee, with objtool
(patch 11) checking it.

On Wed, Oct 28, 2026 at 02:51:40PM +0100, Peter Zijlstra wrote:
>We have -O0 code? I thought we hard relied on building with at least
>-O1, we often get 'fixes' to enable code to build with -O0.

Only crypto/jitterentropy.c, and lpfc when built with GCOV=y. The check
makes no difference for either (lpfc doesn't build at -O0 regardless),
so I'll drop it in v2.

[1] https://lore.kernel.org/all/20240905180758.1396234-1-wentaoz5@xxxxxxxxxxxx/

-- 
Thanks,
Sasha