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

[Josh Poimboeuf <jpoimboe@kernel.org>]

On Thu, Nov 12, 2026 at 10:41:46AM -0800, Josh Poimboeuf wrote:
> 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?

Or rather, sets a watchpoint on a counter specific to
exc_debug_kernel()...  Still, why would somebody do that.

> 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