[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z9a8Uign6ZBmWtZQ@gmail.com>
Date: Sun, 16 Mar 2025 12:56:02 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
Brendan Jackman <jackmanb@...gle.com>,
Nathan Chancellor <nathan@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 13/13] objtool: Add CONFIG_OBJTOOL_WERROR
* Josh Poimboeuf <jpoimboe@...nel.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
Powered by blists - more mailing lists