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

[Josh Poimboeuf <jpoimboe@kernel.org>]

On Fri, Nov 13, 2026 at 10:09:20AM -0500, Sasha Levin wrote:
> 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.

That seems circular though, I'm still trying to figure out what the
actual problem is.

> >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.

FYI, a partial objtool port (without the more controversial CFG
reverse-engineering bits) is likely coming to arm64 soon to support
klp-build, in which case this should be possible there as well.

> 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!

-- 
Josh