Re: [PATCH v2 11/20] objtool: Detect code coverage instrumentation in noinstr code

[Sasha Levin <sashal@kernel.org>]

On Thu, Nov 12, 2026 at 10:41:44AM -0800, Josh Poimboeuf wrote:
>I must be missing something, if somebody sets a watchpoint in
>exc_debug_kernel(), don't they get to keep the pieces?

Fair enough, the watchpoint was just the easiest way to show it. The
real reason is that noinstr isn't supposed to have compiler
instrumentation at all, and inlining sneaks the counters back in.

>It's also not clear why --hack-noinstr can't be extended to either NOP
>out the affected instructions, or change the address relocation to point
>to a dummy variable that won't trap.

I tried it, and I think it works better than patch 4, with some caveats :)

NOPing alone isn't enough: besides MC/DC, Clang sometimes loads a
counter address into a register and increments it later. So I NOP the
plain counter updates and point the rest at a dummy. With GCC that
gets all of them. With Clang, 230 of about 3500 still go to the dummy.

Compared to patch 4, a boot covers about 14% more code, since the
__always_inline helpers it dropped are some of the hottest code we
have. It also fixes a GCC MC/DC build failure and some objtool UACCESS
warnings that patch 4 caused, and it handles modules, which this check
never looked at.

The catch is that it's x86-64 only. Other architectures would stay
where they are today: whatever gets inlined into noinstr keeps its gcov
counters, and nothing checks. Keeping patch 4 just for them doesn't
look worth it to me. It cleans up Clang on arm64, but GCC still has
about 190 counters in noinstr there either way, and the GCC MC/DC
build failure shows up on arm64 too.

Peter, are you OK with fixing this on x86 only and leaving the other
architectures as they are? If so, I'll switch to this in v3 and drop
patch 4.

>And the changelog needs all that background, as the justification is not
>clear at all (to me).

Will do.

--
Thanks,
Sasha