Re: [PATCH 13/13] objtool: Add CONFIG_OBJTOOL_WERROR

[Ingo Molnar <mingo@kernel.org>]

* Josh Poimboeuf <jpoimboe@kernel.org> wrote:

> On Sun, Mar 16, 2025 at 01:41:43AM +0100, Ingo Molnar wrote:
> > > +config OBJTOOL_WERROR
> > > +	bool "Upgrade objtool warnings to errors"
> > > +	default y
> > > +	depends on OBJTOOL && !COMPILE_TEST
> > > +	help
> > > +	  Fail the build on objtool warnings.
> > 
> > This is *way* too aggressive: objtool false positives are still common, 
> 
> I'm not sure what false positives you'd be referring to, these days the
> vast majority of warnings I see are actual bugs.

I'm not sure we are reading the same kernel log :-)

A simple 'git log arch/x86/' followed by a search for objtool pointed 
to the following recent commits:


  #
  # Included a fix for a false positive:
  #
  4e32645cd8f9 x86/smp: Fix mwait_play_dead() and acpi_processor_ffh_play_dead() noreturn behavior

  #
  # objtool poinpointed a problem that has no runtime effects,
  # ie. it's a functional false positive and breaking the build
  # for *that* would have been excessive:
  #
  73e8079be9e7 x86/ibt: Make cfi_bhi a constant for FINEIBT_BHI=n


  #
  # Commit works around an objtool false positive found during development:
  #
  b815f6877d80 x86/bhi: Add BHI stubs


  #
  # Commit works around what appears to be a objtool false positive
  # about too aggressive code generation in function prologues:
  # (An issue that does not seem to trigger in practice.)
  #
  4087e16b0331 x86/locking: Use ALT_OUTPUT_SP() for percpu_{,try_}cmpxchg{64,128}_op()

I literally tried to find the first *actual* bug that objtool prevented 
and the first 4 appear to be struggles with objtool over false 
positives or non-runtime-bugs.

At least in x86 architecture code a significant percentage of objtool 
warnings isn't bugs - and to be fair that's maybe in part due to the 
lockdep effect: developers notice warnings and prevent them, so only 
traces of false positives trickle into the kernel. But lockdep too 
tries to be rather benign and doesn't crash the kernel, it reports an 
issue and turns itself off.

> > and an 'allmodconfig' should not fail the build IMO.
> 
> In fact it doesn't: allmodconfig sets COMPILE_TEST which prevents
> OBJTOOL_WERROR.

Okay, I missed that bit. But the patch still has a 'default y' that 
causes people who didn't have it to enable it by default, right?

> I've had complaints from people who spent days debugging a broken 
> kernel only to discover it was related to an ignored objtool warning.

Same could be said about an ignored lockdep warnings, right?

As long as OBJTOOL_WERROR doesn't get turned on in the primary 8 build 
modes:

  all{mod|yes|no|def}config

and we don't turn it on via default-y I'm a happy camper.

Thanks,

	Ingo