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

[Josh Poimboeuf]

On Thu, Nov 12, 2026 at 04:12:32PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 12, 2026 at 08:09:06AM -0500, Sasha Levin wrote:
> > On Wed, Nov 11, 2026 at 10:23:41PM -0800, Josh Poimboeuf wrote:
> > >What exactly is the problem with noinstr code incrementing counters
> > >inline?
> > 
> > The counter is a memory write, and a memory write can trap. In noinstr
> > code that can happen before we're ready to take another exception.
> > 
> > With GCOV_PROFILE_ALL today, exc_debug_kernel() bumps a counter before
> > it clears DR7. Set a watchpoint on that counter and the next kernel #DB
> > never returns, it just keeps re-entering the handler. I tried it on
> > v7.4-rc1 in a VM and it hangs.
> > 
> > noinstr is already supposed to keep these out, it has had __no_profile
> > for years. But that doesn't cover what gets inlined into it, and nothing
> > checks. This patch adds the check.
> 
> Right, strictly speaking this is a toolchain bug, but since we need to
> build with existing tools we need to bodge it somewhat :/

I must be missing something, if somebody sets a watchpoint in
exc_debug_kernel(), don't they get to keep the pieces?

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.

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

-- 
Josh