public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings
@ 2025-01-13 14:05 Brendan Jackman
  2025-01-13 14:05 ` [PATCH v3 1/2] objtool: Add --Werror Brendan Jackman
                   ` (2 more replies)
  0 siblings, 3 replies; 15+ messages in thread
From: Brendan Jackman @ 2025-01-13 14:05 UTC (permalink / raw)
  To: Josh Poimboeuf, Peter Zijlstra, Andrew Morton, Masahiro Yamada,
	Nathan Chancellor, Nicolas Schier
  Cc: linux-kernel, linux-kbuild, Brendan Jackman

This adds an option to objtool to exit with an error when it enounters
warnings.

Then, it adds a config to enable that flag. This enables you to fail
the build e.g. when noinstr is violated.

When that happens, you also get a more verbose log, for example when
failing noisntr validation it dumps disassembly of the offending code.

Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
Changes in v3:
- Added --verbose to objtool args (equivalent to OBJTOOL_VERBOSE=1, which
  Josh Poimboeuf suggested).
- Link to v2: https://lore.kernel.org/r/20241218-objtool-strict-v2-0-a5297c961434@google.com

Changes in v2:
- Renamed flag/config to -Werror/CONFIG_*_WERROR
- Applied to all objool runs instead of just vmlinux.
- Link to v1: https://lore.kernel.org/r/20241213-objtool-strict-v1-0-fd388f9d971f@google.com

---
Brendan Jackman (2):
      objtool: Add --Werror
      kbuild: Add option to fail build on vmlinux objtool issues

 lib/Kconfig.debug                       | 10 ++++++++++
 scripts/Makefile.lib                    |  1 +
 tools/objtool/builtin-check.c           |  6 ++++++
 tools/objtool/check.c                   |  7 ++-----
 tools/objtool/include/objtool/builtin.h |  1 +
 5 files changed, 20 insertions(+), 5 deletions(-)
---
base-commit: 5bc55a333a2f7316b58edc7573e8e893f7acb532
change-id: 20241213-objtool-strict-cb9a0a75139e

Best regards,
-- 
Brendan Jackman <jackmanb@google.com>


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH v3 1/2] objtool: Add --Werror
  2025-01-13 14:05 [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings Brendan Jackman
@ 2025-01-13 14:05 ` Brendan Jackman
  2025-01-14 17:24   ` Nathan Chancellor
  2025-01-13 14:05 ` [PATCH v3 2/2] kbuild: Add option to fail build on vmlinux objtool issues Brendan Jackman
  2025-01-14  0:14 ` [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings Josh Poimboeuf
  2 siblings, 1 reply; 15+ messages in thread
From: Brendan Jackman @ 2025-01-13 14:05 UTC (permalink / raw)
  To: Josh Poimboeuf, Peter Zijlstra, Andrew Morton, Masahiro Yamada,
	Nathan Chancellor, Nicolas Schier
  Cc: linux-kernel, linux-kbuild, Brendan Jackman

At present objtool only prints to the terminal when observing "fatal
warnings". This option lets you have it produce an error instead.

The use case for this is noinstr validation; so far I've never seen any
false warnings here, but it quite often detects real bugs. It would
be useful for the build to fail when I have those bugs.

Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
 tools/objtool/builtin-check.c           | 6 ++++++
 tools/objtool/check.c                   | 7 ++-----
 tools/objtool/include/objtool/builtin.h | 1 +
 3 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/tools/objtool/builtin-check.c b/tools/objtool/builtin-check.c
index 387d56a7f5fb8da8435d0a3f5c05eeee66932c9b..0b28082df90710ff7127327deb857c0548f378c7 100644
--- a/tools/objtool/builtin-check.c
+++ b/tools/objtool/builtin-check.c
@@ -94,6 +94,12 @@ static const struct option check_options[] = {
 	OPT_BOOLEAN(0, "sec-address", &opts.sec_address, "print section addresses in warnings"),
 	OPT_BOOLEAN(0, "stats", &opts.stats, "print statistics"),
 	OPT_BOOLEAN('v', "verbose", &opts.verbose, "verbose warnings"),
+	/*
+	 *  For now, don't fail the kernel build on fatal warnings by default.
+	 *  These errors are still fairly common due to the growing matrix of
+	 *  supported toolchains and their recent pace of change.
+	 */
+	OPT_BOOLEAN(0, "Werror", &opts.werror, "fail on fatal warnings"),
 
 	OPT_END(),
 };
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 76060da755b5c51cda3a669d8245d7d004e25f22..e44135293eb45f908e00359d84d954cfeddd266f 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -4944,10 +4944,7 @@ int check(struct objtool_file *file)
 	}
 
 out:
-	/*
-	 *  For now, don't fail the kernel build on fatal warnings.  These
-	 *  errors are still fairly common due to the growing matrix of
-	 *  supported toolchains and their recent pace of change.
-	 */
+	if (opts.werror && warnings)
+		return 1;
 	return 0;
 }
diff --git a/tools/objtool/include/objtool/builtin.h b/tools/objtool/include/objtool/builtin.h
index fcca6662c8b4b5e0048e54fada8694cc2e6ebc34..97d668010efadfa05bb6e25e1967a7d72bf77815 100644
--- a/tools/objtool/include/objtool/builtin.h
+++ b/tools/objtool/include/objtool/builtin.h
@@ -38,6 +38,7 @@ struct opts {
 	bool sec_address;
 	bool stats;
 	bool verbose;
+	bool werror;
 };
 
 extern struct opts opts;

-- 
2.47.1.613.gc27f4b7a9f-goog


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [PATCH v3 2/2] kbuild: Add option to fail build on vmlinux objtool issues
  2025-01-13 14:05 [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings Brendan Jackman
  2025-01-13 14:05 ` [PATCH v3 1/2] objtool: Add --Werror Brendan Jackman
@ 2025-01-13 14:05 ` Brendan Jackman
  2025-01-14  0:14 ` [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings Josh Poimboeuf
  2 siblings, 0 replies; 15+ messages in thread
From: Brendan Jackman @ 2025-01-13 14:05 UTC (permalink / raw)
  To: Josh Poimboeuf, Peter Zijlstra, Andrew Morton, Masahiro Yamada,
	Nathan Chancellor, Nicolas Schier
  Cc: linux-kernel, linux-kbuild, Brendan Jackman

NOINSTR_VALIDATION is pretty helpful for detecting bugs, it would be
helpful for the build to fail when those bugs arise.

If necessary it would be possible to enable this for individual
warnings, it seems unlikely there's a use-case for that though. So
for now just add a global setting.

When the this new option, OBJTOOL_WERROR, is set, also add --verbose:
if the build is failing then it's better to spit out any information
that might help diagnose the failure, even if that risks a very verbose
output.

Checkpatch-args: --ignore=CONFIG_DESCRIPTION
Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
 lib/Kconfig.debug    | 10 ++++++++++
 scripts/Makefile.lib |  1 +
 2 files changed, 11 insertions(+)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index f3d72370587936fa373129cc9b246f15dac907be..3ee92da4733a3a504991d5dbb4d0cee84f519d64 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -545,6 +545,16 @@ config FRAME_POINTER
 config OBJTOOL
 	bool
 
+config OBJTOOL_WERROR
+	bool "Run objtool with warnings as errors"
+	default n
+	depends on OBJTOOL
+	help
+	  Fail the build when objtool produces warnings.
+
+	  By default, objtool just prints warnings to the terminal without
+	  causing a build failure. This config changes that.
+
 config STACK_VALIDATION
 	bool "Compile-time stack metadata validation"
 	depends on HAVE_STACK_VALIDATION && UNWINDER_FRAME_POINTER
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 7395200538da89a2f6e6d21f8959f3f60d291d79..a1b264e532920dd649122968d5782ca8eff34ad9 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -277,6 +277,7 @@ objtool-args-$(CONFIG_HAVE_STATIC_CALL_INLINE)		+= --static-call
 objtool-args-$(CONFIG_HAVE_UACCESS_VALIDATION)		+= --uaccess
 objtool-args-$(CONFIG_GCOV_KERNEL)			+= --no-unreachable
 objtool-args-$(CONFIG_PREFIX_SYMBOLS)			+= --prefix=$(CONFIG_FUNCTION_PADDING_BYTES)
+objtool-args-$(CONFIG_OBJTOOL_WERROR)			+= --Werror --verbose
 
 objtool-args = $(objtool-args-y)					\
 	$(if $(delay-objtool), --link)					\

-- 
2.47.1.613.gc27f4b7a9f-goog


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings
  2025-01-13 14:05 [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings Brendan Jackman
  2025-01-13 14:05 ` [PATCH v3 1/2] objtool: Add --Werror Brendan Jackman
  2025-01-13 14:05 ` [PATCH v3 2/2] kbuild: Add option to fail build on vmlinux objtool issues Brendan Jackman
@ 2025-01-14  0:14 ` Josh Poimboeuf
  2025-01-30 15:55   ` Brendan Jackman
  2 siblings, 1 reply; 15+ messages in thread
From: Josh Poimboeuf @ 2025-01-14  0:14 UTC (permalink / raw)
  To: Brendan Jackman
  Cc: Peter Zijlstra, Andrew Morton, Masahiro Yamada, Nathan Chancellor,
	Nicolas Schier, linux-kernel, linux-kbuild

On Mon, Jan 13, 2025 at 02:05:14PM +0000, Brendan Jackman wrote:
> This adds an option to objtool to exit with an error when it enounters
> warnings.
> 
> Then, it adds a config to enable that flag. This enables you to fail
> the build e.g. when noinstr is violated.
> 
> When that happens, you also get a more verbose log, for example when
> failing noisntr validation it dumps disassembly of the offending code.
> 
> Signed-off-by: Brendan Jackman <jackmanb@google.com>
> ---
> Changes in v3:
> - Added --verbose to objtool args (equivalent to OBJTOOL_VERBOSE=1, which
>   Josh Poimboeuf suggested).
> - Link to v2: https://lore.kernel.org/r/20241218-objtool-strict-v2-0-a5297c961434@google.com

Thanks!  I'm putting it through bot testing now.

-- 
Josh

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 1/2] objtool: Add --Werror
  2025-01-13 14:05 ` [PATCH v3 1/2] objtool: Add --Werror Brendan Jackman
@ 2025-01-14 17:24   ` Nathan Chancellor
  2025-01-14 18:17     ` Josh Poimboeuf
  0 siblings, 1 reply; 15+ messages in thread
From: Nathan Chancellor @ 2025-01-14 17:24 UTC (permalink / raw)
  To: Brendan Jackman
  Cc: Josh Poimboeuf, Peter Zijlstra, Andrew Morton, Masahiro Yamada,
	Nicolas Schier, linux-kernel, linux-kbuild

On Mon, Jan 13, 2025 at 02:05:15PM +0000, Brendan Jackman wrote:
> At present objtool only prints to the terminal when observing "fatal
> warnings". This option lets you have it produce an error instead.
> 
> The use case for this is noinstr validation; so far I've never seen any
> false warnings here, but it quite often detects real bugs. It would
> be useful for the build to fail when I have those bugs.
> 
> Signed-off-by: Brendan Jackman <jackmanb@google.com>
> ---
>  tools/objtool/builtin-check.c           | 6 ++++++
>  tools/objtool/check.c                   | 7 ++-----
>  tools/objtool/include/objtool/builtin.h | 1 +
>  3 files changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/objtool/builtin-check.c b/tools/objtool/builtin-check.c
> index 387d56a7f5fb8da8435d0a3f5c05eeee66932c9b..0b28082df90710ff7127327deb857c0548f378c7 100644
> --- a/tools/objtool/builtin-check.c
> +++ b/tools/objtool/builtin-check.c
> @@ -94,6 +94,12 @@ static const struct option check_options[] = {
>  	OPT_BOOLEAN(0, "sec-address", &opts.sec_address, "print section addresses in warnings"),
>  	OPT_BOOLEAN(0, "stats", &opts.stats, "print statistics"),
>  	OPT_BOOLEAN('v', "verbose", &opts.verbose, "verbose warnings"),
> +	/*
> +	 *  For now, don't fail the kernel build on fatal warnings by default.
> +	 *  These errors are still fairly common due to the growing matrix of
> +	 *  supported toolchains and their recent pace of change.
> +	 */
> +	OPT_BOOLEAN(0, "Werror", &opts.werror, "fail on fatal warnings"),
>  
>  	OPT_END(),
>  };
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index 76060da755b5c51cda3a669d8245d7d004e25f22..e44135293eb45f908e00359d84d954cfeddd266f 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -4944,10 +4944,7 @@ int check(struct objtool_file *file)
>  	}
>  
>  out:
> -	/*
> -	 *  For now, don't fail the kernel build on fatal warnings.  These
> -	 *  errors are still fairly common due to the growing matrix of
> -	 *  supported toolchains and their recent pace of change.
> -	 */
> +	if (opts.werror && warnings)

It might be a good idea to print a message here about why the build is
failing, in lieu of turning all "objtool: warning:" messages into
"objtool: error:" messages ala -Werror for C compilers, which does not
seem simple on quick glance. Otherwise, I am not entirely sure it will
be obvious to people why a build like allmodconfig may start failing if
this configuration gets turned on.

https://lore.kernel.org/Z4X8j%2FqJj7ib0vkh@rli9-mobl/

> +		return 1;
>  	return 0;
>  }
> diff --git a/tools/objtool/include/objtool/builtin.h b/tools/objtool/include/objtool/builtin.h
> index fcca6662c8b4b5e0048e54fada8694cc2e6ebc34..97d668010efadfa05bb6e25e1967a7d72bf77815 100644
> --- a/tools/objtool/include/objtool/builtin.h
> +++ b/tools/objtool/include/objtool/builtin.h
> @@ -38,6 +38,7 @@ struct opts {
>  	bool sec_address;
>  	bool stats;
>  	bool verbose;
> +	bool werror;
>  };
>  
>  extern struct opts opts;
> 
> -- 
> 2.47.1.613.gc27f4b7a9f-goog
> 

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 1/2] objtool: Add --Werror
  2025-01-14 17:24   ` Nathan Chancellor
@ 2025-01-14 18:17     ` Josh Poimboeuf
  0 siblings, 0 replies; 15+ messages in thread
From: Josh Poimboeuf @ 2025-01-14 18:17 UTC (permalink / raw)
  To: Nathan Chancellor
  Cc: Brendan Jackman, Peter Zijlstra, Andrew Morton, Masahiro Yamada,
	Nicolas Schier, linux-kernel, linux-kbuild

On Tue, Jan 14, 2025 at 10:24:29AM -0700, Nathan Chancellor wrote:
> 
> It might be a good idea to print a message here about why the build is
> failing, in lieu of turning all "objtool: warning:" messages into
> "objtool: error:" messages ala -Werror for C compilers, which does not
> seem simple on quick glance. Otherwise, I am not entirely sure it will
> be obvious to people why a build like allmodconfig may start failing if
> this configuration gets turned on.
> 
> https://lore.kernel.org/Z4X8j%2FqJj7ib0vkh@rli9-mobl/

Yeah, makes sense.  I'll add this:

From: Josh Poimboeuf <jpoimboe@kernel.org>
Subject: [PATCH] objtool: Change "warning:" to "error:" for CONFIG_OBJTOOL_WERROR

This matches GCC's behavior and makes it more obvious why the build
failed.

Suggested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
 tools/objtool/include/objtool/warn.h | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/objtool/include/objtool/warn.h b/tools/objtool/include/objtool/warn.h
index ac04d3fe4dd9..78f602b5daed 100644
--- a/tools/objtool/include/objtool/warn.h
+++ b/tools/objtool/include/objtool/warn.h
@@ -43,8 +43,10 @@ static inline char *offstr(struct section *sec, unsigned long offset)
 
 #define WARN(format, ...)				\
 	fprintf(stderr,					\
-		"%s: warning: objtool: " format "\n",	\
-		objname, ##__VA_ARGS__)
+		"%s: %s: objtool: " format "\n",	\
+		objname,				\
+		opts.werror ? "error" : "warning",	\
+		##__VA_ARGS__)
 
 #define WARN_FUNC(format, sec, offset, ...)		\
 ({							\
-- 
2.47.1


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings
  2025-01-14  0:14 ` [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings Josh Poimboeuf
@ 2025-01-30 15:55   ` Brendan Jackman
  2025-01-30 18:30     ` Nathan Chancellor
  0 siblings, 1 reply; 15+ messages in thread
From: Brendan Jackman @ 2025-01-30 15:55 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Peter Zijlstra, Andrew Morton, Masahiro Yamada, Nathan Chancellor,
	Nicolas Schier, linux-kernel, linux-kbuild

On Tue, 14 Jan 2025 at 01:14, Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> Thanks!  I'm putting it through bot testing now.

Hey Josh, how has it been going - could we merge the feature?

(Or, has it already been merged in some tree that doesn't go into linux-next?)

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings
  2025-01-30 15:55   ` Brendan Jackman
@ 2025-01-30 18:30     ` Nathan Chancellor
  2025-01-31 10:44       ` Brendan Jackman
  0 siblings, 1 reply; 15+ messages in thread
From: Nathan Chancellor @ 2025-01-30 18:30 UTC (permalink / raw)
  To: Brendan Jackman
  Cc: Josh Poimboeuf, Peter Zijlstra, Andrew Morton, Masahiro Yamada,
	Nicolas Schier, linux-kernel, linux-kbuild

On Thu, Jan 30, 2025 at 04:55:39PM +0100, Brendan Jackman wrote:
> On Tue, 14 Jan 2025 at 01:14, Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> > Thanks!  I'm putting it through bot testing now.
> 
> Hey Josh, how has it been going - could we merge the feature?
> 
> (Or, has it already been merged in some tree that doesn't go into linux-next?)

It looks like it is in Josh's tree but that tree does not flow into
-next; IIRC, they have to be merged into -tip to show up there.

https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/log/?h=objtool/core

For the record, this will be disruptive for clang users because a number
of warnings have crept up in recent releases and this option will get
enabled for allmodconfig. I have started going through them all but I am
working at an unfortunate intersection between compiler/optimization
internals, other flags such as sanitizers, and reconstructing control
flow. Most of them are "falls through to the next function" or
"unexpected end of section" warnings, which generally mean some
undefined behavior has been encountered and clang has given up code
generation. Figuring out what changed on the LLVM side requires a bisect
then reporting it (if it is a legitimate compiler problem) requires a
source file reduction. I did explore turning unreachable into a trap to
fix several of those but I think that will need further objtool changes
to cure the warnings that were reported:

https://lore.kernel.org/all/?q=llvm-trap-unreachable

I think Josh already mentioned it but exposing -Werror for objtool is a
big committment. Any time the build breaks because of it (even due to
external factors such as a compiler upgrade), there will be a need for
triage and just saying "turn off CONFIG_OBJTOOL_WERROR" cannot always be
the solution otherwise it loses its power. While it is nice leverage to
keep things clean (and I feel like it has generally worked well for
compilers with CONFIG_WERROR), it is disruptive and requires real labor
to upkeep, which should be from the authors who introduce the warnings
but they might need guidance or advice. I am regularly helping people
with figuring out issues from the LLVM toolchain becuase they get a
report that they have broken something but they do not use LLVM so they
are unsure what to do or what it means. I am not saying this is all a
bad idea but I want to make sure that this committment has been
considered.

If exposing this to the world feels too premature, maybe the flag could
be added then have a make variable like OBJTOOL_FLAGS to allow a
developer to pass it through if they wish?

Cheers,
Nathan

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings
  2025-01-30 18:30     ` Nathan Chancellor
@ 2025-01-31 10:44       ` Brendan Jackman
  2025-01-31 20:49         ` Nathan Chancellor
  0 siblings, 1 reply; 15+ messages in thread
From: Brendan Jackman @ 2025-01-31 10:44 UTC (permalink / raw)
  To: Nathan Chancellor
  Cc: Josh Poimboeuf, Peter Zijlstra, Andrew Morton, Masahiro Yamada,
	Nicolas Schier, linux-kernel, linux-kbuild

On Thu, 30 Jan 2025 at 19:30, Nathan Chancellor <nathan@kernel.org> wrote:
> It looks like it is in Josh's tree but that tree does not flow into
> -next; IIRC, they have to be merged into -tip to show up there.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/log/?h=objtool/core

Ah nice - thanks for the info.

> For the record, this will be disruptive for clang users because a number
> of warnings have crept up in recent releases and this option will get
> enabled for allmodconfig.
[snip]
> I think Josh already mentioned it but exposing -Werror for objtool is a
> big committment.

OK yeah, I hadn't really taken the implications on board, i.e. I
hadn't really internalised the fact that this affects builds where the
user didn't explicitly opt-in to strictness.

Do you have a mental picture of how sources of objtool regressions are
distributed in the kernel? I'm wondering if it would be alleviated if
we enabled it for stuff like defconfig and tinyconfig, while disabling
it for allmodconfig/allyesconfig. Looks like LTO_CLANG_FULL does the
latter (forcefully) by depending on !COMPILE_TEST, maybe there's
another way.

But I can also envisage a world where that creates exactly as much
work for you, just introducing Kconfig hackery for no reason!

> If exposing this to the world feels too premature, maybe the flag could
> be added then have a make variable like OBJTOOL_FLAGS to allow a
> developer to pass it through if they wish?

Yeah, that would definitely be a reasonable start.

I'll wait and see if Josh has any additional thoughts.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings
  2025-01-31 10:44       ` Brendan Jackman
@ 2025-01-31 20:49         ` Nathan Chancellor
  2025-02-06 15:05           ` Brendan Jackman
  0 siblings, 1 reply; 15+ messages in thread
From: Nathan Chancellor @ 2025-01-31 20:49 UTC (permalink / raw)
  To: Brendan Jackman
  Cc: Josh Poimboeuf, Peter Zijlstra, Andrew Morton, Masahiro Yamada,
	Nicolas Schier, linux-kernel, linux-kbuild

On Fri, Jan 31, 2025 at 11:44:46AM +0100, Brendan Jackman wrote:
> On Thu, 30 Jan 2025 at 19:30, Nathan Chancellor <nathan@kernel.org> wrote:
> > For the record, this will be disruptive for clang users because a number
> > of warnings have crept up in recent releases and this option will get
> > enabled for allmodconfig.
> [snip]
> > I think Josh already mentioned it but exposing -Werror for objtool is a
> > big committment.
> 
> OK yeah, I hadn't really taken the implications on board, i.e. I
> hadn't really internalised the fact that this affects builds where the
> user didn't explicitly opt-in to strictness.
>
> Do you have a mental picture of how sources of objtool regressions are
> distributed in the kernel? I'm wondering if it would be alleviated if
> we enabled it for stuff like defconfig and tinyconfig, while disabling
> it for allmodconfig/allyesconfig. Looks like LTO_CLANG_FULL does the
> latter (forcefully) by depending on !COMPILE_TEST, maybe there's
> another way.

I do not have a good high level overview yet since I have only just
started combing over them in addition to all of my other work keeping
the tree green and our CI running.

I can at least provide an overview of what my most recent build of
linux-next with a close to tip of tree clang shows. I have sorted it two
different ways.

The first is showing what builds have warnings.

-----------------------------------------------

loongarch-defconfig-CONFIG_LTO_CLANG_THIN=y.log
	drivers/gpu/drm/amd/amdgpu/amdgpu.o: warning: objtool: .text.dc_fixpt_recip: unexpected end of section
	vmlinux.o: warning: objtool: .text.crash_shutdown_secondary: unexpected end of section
	vmlinux.o: warning: objtool: .text.kexec_reboot: unexpected end of section
	vmlinux.o: warning: objtool: .text.kexec_shutdown_secondary: unexpected end of section
	vmlinux.o: warning: objtool: .text.machine_kexec: unexpected end of section
	vmlinux.o: warning: objtool: ___bpf_prog_run+0x64: sibling call from callable instruction with modified stack frame
	vmlinux.o: warning: objtool: __efistub_efi_boot_kernel() falls through to next function __efistub_exit_boot_func()

loongarch-defconfig.log
	arch/loongarch/kernel/machine_kexec.o: warning: objtool: .text: unexpected end of section
	arch/loongarch/kernel/machine_kexec.o: warning: objtool: crash_shutdown_secondary() falls through to next function machine_shutdown()
	arch/loongarch/kernel/machine_kexec.o: warning: objtool: kexec_reboot() falls through to next function crash_smp_send_stop()
	arch/loongarch/kernel/machine_kexec.o: warning: objtool: kexec_shutdown_secondary() falls through to next function machine_kexec()
	drivers/gpu/drm/amd/amdgpu/../display/dc/basics/fixpt31_32.o: warning: objtool: dc_fixpt_recip() falls through to next function dc_fixpt_sinc()
	kernel/bpf/core.o: warning: objtool: ___bpf_prog_run+0x64: sibling call from callable instruction with modified stack frame

x86_64-allmodconfig-CONFIG_GCOV_KERNEL=n-CONFIG_KASAN=n-CONFIG_LTO_CLANG_THIN=y-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log
	drivers/gpu/drm/msm/msm.o: warning: objtool: .text.msm_dp_catalog_ctrl_config_msa: unexpected end of section
	drivers/iio/adc/at91-sama5d2_adc.o: warning: objtool: .text.at91_adc_probe: unexpected end of section
	drivers/media/dvb-frontends/dib8000.o: warning: objtool: .text.dib8000_tune: unexpected end of section
	drivers/media/dvb-frontends/rtl2832_sdr.o: warning: objtool: .text.rtl2832_sdr_s_fmt_sdr_cap: unexpected end of section
	drivers/media/dvb-frontends/rtl2832_sdr.o: warning: objtool: .text.rtl2832_sdr_try_fmt_sdr_cap: unexpected end of section
	drivers/media/i2c/mt9t112.o: warning: objtool: .text.mt9t112_set_fmt: unexpected end of section
	drivers/media/i2c/mt9t112.o: warning: objtool: .text.mt9t112_set_params: unexpected end of section
	drivers/media/usb/msi2500/msi2500.o: warning: objtool: .text.msi2500_s_fmt_sdr_cap: unexpected end of section
	drivers/media/usb/msi2500/msi2500.o: warning: objtool: .text.msi2500_try_fmt_sdr_cap: unexpected end of section
	drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.o: warning: objtool: .text.mlx5e_mpwrq_mtts_per_wqe: unexpected end of section
	drivers/nvme/target/nvmet.o: warning: objtool: .text.nvmet_ctrl_state_show: unexpected end of section
	drivers/pci/endpoint/functions/pci-epf-test.o: warning: objtool: .text.pci_epf_test_cmd_handler: unexpected end of section
	drivers/regulator/rk808-regulator.o: warning: objtool: .text.rk806_set_mode_dcdc: unexpected end of section
	drivers/spi/spi-amd.o: warning: objtool: .text.amd_set_spi_freq: unexpected end of section
	sound/soc/codecs/snd-soc-wcd9335.o: warning: objtool: .text.wcd9335_slimbus_irq: unexpected end of section
	sound/soc/codecs/snd-soc-wcd934x.o: warning: objtool: .text.wcd934x_slim_irq_handler: unexpected end of section
	vmlinux.o: warning: objtool: do_user_addr_fault+0xe5b: unreachable instruction

x86_64-allmodconfig-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log
	drivers/gpu/drm/msm/msm.o: warning: objtool: msm_dp_catalog_ctrl_config_msa() falls through to next function __cfi_msm_dp_catalog_ctrl_set_pattern_state_bit()
	drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()
	drivers/media/pci/solo6x10/solo6x10.o: warning: objtool: tw28_set_ctrl_val() falls through to next function __cfi_tw28_get_ctrl_val()
	drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.o: warning: objtool: mlx5e_mpwrq_mtts_per_wqe() falls through to next function __cfi_mlx5e_mpwrq_max_num_entries()
	drivers/nvme/target/nvmet.o: warning: objtool: nvmet_ctrl_state_show() falls through to next function __cfi_nvmet_ctrl_host_traddr_open()
	drivers/regulator/rk808-regulator.o: warning: objtool: rk806_set_mode_dcdc() falls through to next function __cfi_rk806_get_mode_dcdc()
	drivers/spi/spi-amd.o: warning: objtool: amd_set_spi_freq() falls through to next function amd_spi_busy_wait()
	sound/soc/codecs/snd-soc-wcd9335.o: warning: objtool: wcd9335_slimbus_irq() falls through to next function __cfi_wcd9335_set_channel_map()
	sound/soc/codecs/snd-soc-wcd934x.o: warning: objtool: wcd934x_slim_irq_handler() falls through to next function __cfi_swclk_gate_disable()

x86_64-alpine-config.log
	arch/x86/kernel/head_64.o: warning: objtool: xen_hypercall_hvm+0x30: sibling call from callable instruction with modified stack frame
	drivers/bluetooth/hci_vhci.o: warning: objtool: vhci_coredump_hdr() falls through to next function vhci_open_timeout()
	drivers/gpu/drm/amd/amdgpu/../display/dc/basics/fixpt31_32.o: warning: objtool: dc_fixpt_recip() falls through to next function dc_fixpt_sinc()
	drivers/gpu/drm/amd/amdgpu/../display/dc/spl/spl_fixpt31_32.o: warning: objtool: spl_fixpt_recip() falls through to next function spl_fixpt_sinc()
	drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_set_frontend() falls through to next function dib8000_fe_get_tune_settings()
	drivers/net/ethernet/jme.o: warning: objtool: jme_check_link() falls through to next function jme_powersave_phy()
	drivers/net/ethernet/mellanox/mlx5/core/en/params.o: warning: objtool: mlx5e_mpwrq_max_log_rq_size() falls through to next function mlx5e_get_linear_rq_headroom()
	drivers/net/ethernet/mellanox/mlx5/core/en/params.o: warning: objtool: mlx5e_mpwrq_mtts_per_wqe() falls through to next function mlx5e_mpwrq_max_num_entries()
	fs/bcachefs/btree_update_interior.o: warning: objtool: bch2_btree_split_leaf() falls through to next function bch2_btree_update_start()

x86_64-archlinux-config.log
	drivers/gpu/drm/amd/amdgpu/amdgpu.o: warning: objtool: dc_fixpt_recip() falls through to next function dc_fixpt_sinc()
	drivers/gpu/drm/amd/amdgpu/amdgpu.o: warning: objtool: spl_fixpt_recip() falls through to next function spl_fixpt_sinc()
	drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_set_frontend() falls through to next function dib8000_fe_get_tune_settings()
	drivers/media/i2c/ccs/ccs.o: warning: objtool: ccs_set_selection() falls through to next function ccs_propagate()
	drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.o: warning: objtool: mlx5e_mpwrq_max_log_rq_size() falls through to next function mlx5e_get_linear_rq_headroom()
	drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.o: warning: objtool: mlx5e_mpwrq_mtts_per_wqe() falls through to next function mlx5e_mpwrq_max_num_entries()

x86_64-debian-config.log
	drivers/gpu/drm/amd/amdgpu/amdgpu.o: warning: objtool: dc_fixpt_recip() falls through to next function dc_fixpt_sinc()
	drivers/gpu/drm/amd/amdgpu/amdgpu.o: warning: objtool: spl_fixpt_recip() falls through to next function spl_fixpt_sinc()
	drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_set_frontend() falls through to next function dib8000_fe_get_tune_settings()
	drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.o: warning: objtool: mlx5e_mpwrq_max_log_rq_size() falls through to next function mlx5e_get_linear_rq_headroom()
	drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.o: warning: objtool: mlx5e_mpwrq_mtts_per_wqe() falls through to next function mlx5e_mpwrq_max_num_entries()

x86_64-fedora-config.log
	drivers/gpu/drm/amd/amdgpu/amdgpu.o: warning: objtool: dc_fixpt_recip() falls through to next function dc_fixpt_sinc()
	drivers/gpu/drm/amd/amdgpu/amdgpu.o: warning: objtool: spl_fixpt_recip() falls through to next function spl_fixpt_sinc()
	drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_set_frontend() falls through to next function dib8000_fe_get_tune_settings()
	drivers/media/i2c/ccs/ccs.o: warning: objtool: ccs_set_selection() falls through to next function ccs_propagate()
	drivers/media/pci/solo6x10/solo6x10.o: warning: objtool: tw28_set_ctrl_val() falls through to next function tw28_get_ctrl_val()
	drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.o: warning: objtool: mlx5e_mpwrq_max_log_rq_size() falls through to next function mlx5e_get_linear_rq_headroom()
	drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.o: warning: objtool: mlx5e_mpwrq_mtts_per_wqe() falls through to next function mlx5e_mpwrq_max_num_entries()

x86_64-opensuse-config.log
	drivers/bluetooth/hci_vhci.o: warning: objtool: vhci_coredump_hdr() falls through to next function vhci_open_timeout()
	drivers/gpu/drm/amd/amdgpu/amdgpu.o: warning: objtool: dc_fixpt_recip() falls through to next function dc_fixpt_sinc()
	drivers/gpu/drm/amd/amdgpu/amdgpu.o: warning: objtool: spl_fixpt_recip() falls through to next function spl_fixpt_sinc()
	drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_set_frontend() falls through to next function dib8000_fe_get_tune_settings()
	drivers/media/i2c/ccs/ccs.o: warning: objtool: ccs_set_selection() falls through to next function ccs_propagate()
	drivers/misc/lkdtm/lkdtm.o: warning: objtool: execute_location+0x4f: relocation to !ENDBR: .text+0x11a8
	drivers/net/ethernet/jme.o: warning: objtool: jme_check_link() falls through to next function jme_powersave_phy()
	drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.o: warning: objtool: mlx5e_mpwrq_max_log_rq_size() falls through to next function mlx5e_get_linear_rq_headroom()
	drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.o: warning: objtool: mlx5e_mpwrq_mtts_per_wqe() falls through to next function mlx5e_mpwrq_max_num_entries()

-----------------------------------------------

The second way is looking at warnings and what configurations they
appear in. You will notice there are a good number of warnings that
appear only in allmodconfig, so that could point to a sanitizer causing
some weird behavior with code generation.

-----------------------------------------------

drivers/gpu/drm/amd/amdgpu/amdgpu.o: warning: objtool: .text.dc_fixpt_recip: unexpected end of section
	loongarch-defconfig-CONFIG_LTO_CLANG_THIN=y.log

vmlinux.o: warning: objtool: .text.crash_shutdown_secondary: unexpected end of section
	loongarch-defconfig-CONFIG_LTO_CLANG_THIN=y.log

vmlinux.o: warning: objtool: .text.kexec_reboot: unexpected end of section
	loongarch-defconfig-CONFIG_LTO_CLANG_THIN=y.log

vmlinux.o: warning: objtool: .text.kexec_shutdown_secondary: unexpected end of section
	loongarch-defconfig-CONFIG_LTO_CLANG_THIN=y.log

vmlinux.o: warning: objtool: .text.machine_kexec: unexpected end of section
	loongarch-defconfig-CONFIG_LTO_CLANG_THIN=y.log

vmlinux.o: warning: objtool: ___bpf_prog_run+0x64: sibling call from callable instruction with modified stack frame
	loongarch-defconfig-CONFIG_LTO_CLANG_THIN=y.log

vmlinux.o: warning: objtool: __efistub_efi_boot_kernel() falls through to next function __efistub_exit_boot_func()
	loongarch-defconfig-CONFIG_LTO_CLANG_THIN=y.log

arch/loongarch/kernel/machine_kexec.o: warning: objtool: .text: unexpected end of section
	loongarch-defconfig.log

arch/loongarch/kernel/machine_kexec.o: warning: objtool: crash_shutdown_secondary() falls through to next function machine_shutdown()
	loongarch-defconfig.log

arch/loongarch/kernel/machine_kexec.o: warning: objtool: kexec_reboot() falls through to next function crash_smp_send_stop()
	loongarch-defconfig.log

arch/loongarch/kernel/machine_kexec.o: warning: objtool: kexec_shutdown_secondary() falls through to next function machine_kexec()
	loongarch-defconfig.log

drivers/gpu/drm/amd/amdgpu/../display/dc/basics/fixpt31_32.o: warning: objtool: dc_fixpt_recip() falls through to next function dc_fixpt_sinc()
	loongarch-defconfig.log
	x86_64-alpine-config.log

kernel/bpf/core.o: warning: objtool: ___bpf_prog_run+0x64: sibling call from callable instruction with modified stack frame
	loongarch-defconfig.log

drivers/gpu/drm/msm/msm.o: warning: objtool: .text.msm_dp_catalog_ctrl_config_msa: unexpected end of section
	x86_64-allmodconfig-CONFIG_GCOV_KERNEL=n-CONFIG_KASAN=n-CONFIG_LTO_CLANG_THIN=y-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

drivers/iio/adc/at91-sama5d2_adc.o: warning: objtool: .text.at91_adc_probe: unexpected end of section
	x86_64-allmodconfig-CONFIG_GCOV_KERNEL=n-CONFIG_KASAN=n-CONFIG_LTO_CLANG_THIN=y-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

drivers/media/dvb-frontends/dib8000.o: warning: objtool: .text.dib8000_tune: unexpected end of section
	x86_64-allmodconfig-CONFIG_GCOV_KERNEL=n-CONFIG_KASAN=n-CONFIG_LTO_CLANG_THIN=y-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

drivers/media/dvb-frontends/rtl2832_sdr.o: warning: objtool: .text.rtl2832_sdr_s_fmt_sdr_cap: unexpected end of section
	x86_64-allmodconfig-CONFIG_GCOV_KERNEL=n-CONFIG_KASAN=n-CONFIG_LTO_CLANG_THIN=y-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

drivers/media/dvb-frontends/rtl2832_sdr.o: warning: objtool: .text.rtl2832_sdr_try_fmt_sdr_cap: unexpected end of section
	x86_64-allmodconfig-CONFIG_GCOV_KERNEL=n-CONFIG_KASAN=n-CONFIG_LTO_CLANG_THIN=y-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

drivers/media/i2c/mt9t112.o: warning: objtool: .text.mt9t112_set_fmt: unexpected end of section
	x86_64-allmodconfig-CONFIG_GCOV_KERNEL=n-CONFIG_KASAN=n-CONFIG_LTO_CLANG_THIN=y-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

drivers/media/i2c/mt9t112.o: warning: objtool: .text.mt9t112_set_params: unexpected end of section
	x86_64-allmodconfig-CONFIG_GCOV_KERNEL=n-CONFIG_KASAN=n-CONFIG_LTO_CLANG_THIN=y-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

drivers/media/usb/msi2500/msi2500.o: warning: objtool: .text.msi2500_s_fmt_sdr_cap: unexpected end of section
	x86_64-allmodconfig-CONFIG_GCOV_KERNEL=n-CONFIG_KASAN=n-CONFIG_LTO_CLANG_THIN=y-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

drivers/media/usb/msi2500/msi2500.o: warning: objtool: .text.msi2500_try_fmt_sdr_cap: unexpected end of section
	x86_64-allmodconfig-CONFIG_GCOV_KERNEL=n-CONFIG_KASAN=n-CONFIG_LTO_CLANG_THIN=y-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.o: warning: objtool: .text.mlx5e_mpwrq_mtts_per_wqe: unexpected end of section
	x86_64-allmodconfig-CONFIG_GCOV_KERNEL=n-CONFIG_KASAN=n-CONFIG_LTO_CLANG_THIN=y-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

drivers/nvme/target/nvmet.o: warning: objtool: .text.nvmet_ctrl_state_show: unexpected end of section
	x86_64-allmodconfig-CONFIG_GCOV_KERNEL=n-CONFIG_KASAN=n-CONFIG_LTO_CLANG_THIN=y-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

drivers/pci/endpoint/functions/pci-epf-test.o: warning: objtool: .text.pci_epf_test_cmd_handler: unexpected end of section
	x86_64-allmodconfig-CONFIG_GCOV_KERNEL=n-CONFIG_KASAN=n-CONFIG_LTO_CLANG_THIN=y-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

drivers/regulator/rk808-regulator.o: warning: objtool: .text.rk806_set_mode_dcdc: unexpected end of section
	x86_64-allmodconfig-CONFIG_GCOV_KERNEL=n-CONFIG_KASAN=n-CONFIG_LTO_CLANG_THIN=y-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

drivers/spi/spi-amd.o: warning: objtool: .text.amd_set_spi_freq: unexpected end of section
	x86_64-allmodconfig-CONFIG_GCOV_KERNEL=n-CONFIG_KASAN=n-CONFIG_LTO_CLANG_THIN=y-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

sound/soc/codecs/snd-soc-wcd9335.o: warning: objtool: .text.wcd9335_slimbus_irq: unexpected end of section
	x86_64-allmodconfig-CONFIG_GCOV_KERNEL=n-CONFIG_KASAN=n-CONFIG_LTO_CLANG_THIN=y-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

sound/soc/codecs/snd-soc-wcd934x.o: warning: objtool: .text.wcd934x_slim_irq_handler: unexpected end of section
	x86_64-allmodconfig-CONFIG_GCOV_KERNEL=n-CONFIG_KASAN=n-CONFIG_LTO_CLANG_THIN=y-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

vmlinux.o: warning: objtool: do_user_addr_fault+0xe5b: unreachable instruction
	x86_64-allmodconfig-CONFIG_GCOV_KERNEL=n-CONFIG_KASAN=n-CONFIG_LTO_CLANG_THIN=y-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

drivers/gpu/drm/msm/msm.o: warning: objtool: msm_dp_catalog_ctrl_config_msa() falls through to next function __cfi_msm_dp_catalog_ctrl_set_pattern_state_bit()
	x86_64-allmodconfig-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()
	x86_64-allmodconfig-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

drivers/media/pci/solo6x10/solo6x10.o: warning: objtool: tw28_set_ctrl_val() falls through to next function __cfi_tw28_get_ctrl_val()
	x86_64-allmodconfig-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.o: warning: objtool: mlx5e_mpwrq_mtts_per_wqe() falls through to next function __cfi_mlx5e_mpwrq_max_num_entries()
	x86_64-allmodconfig-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

drivers/nvme/target/nvmet.o: warning: objtool: nvmet_ctrl_state_show() falls through to next function __cfi_nvmet_ctrl_host_traddr_open()
	x86_64-allmodconfig-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

drivers/regulator/rk808-regulator.o: warning: objtool: rk806_set_mode_dcdc() falls through to next function __cfi_rk806_get_mode_dcdc()
	x86_64-allmodconfig-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

drivers/spi/spi-amd.o: warning: objtool: amd_set_spi_freq() falls through to next function amd_spi_busy_wait()
	x86_64-allmodconfig-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

sound/soc/codecs/snd-soc-wcd9335.o: warning: objtool: wcd9335_slimbus_irq() falls through to next function __cfi_wcd9335_set_channel_map()
	x86_64-allmodconfig-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

sound/soc/codecs/snd-soc-wcd934x.o: warning: objtool: wcd934x_slim_irq_handler() falls through to next function __cfi_swclk_gate_disable()
	x86_64-allmodconfig-CONFIG_WERROR=n-CONFIG_DRM_WERROR=n.log

arch/x86/kernel/head_64.o: warning: objtool: xen_hypercall_hvm+0x30: sibling call from callable instruction with modified stack frame
	x86_64-alpine-config.log

drivers/bluetooth/hci_vhci.o: warning: objtool: vhci_coredump_hdr() falls through to next function vhci_open_timeout()
	x86_64-alpine-config.log
	x86_64-opensuse-config.log

drivers/gpu/drm/amd/amdgpu/../display/dc/spl/spl_fixpt31_32.o: warning: objtool: spl_fixpt_recip() falls through to next function spl_fixpt_sinc()
	x86_64-alpine-config.log

drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_set_frontend() falls through to next function dib8000_fe_get_tune_settings()
	x86_64-alpine-config.log
	x86_64-archlinux-config.log
	x86_64-debian-config.log
	x86_64-fedora-config.log
	x86_64-opensuse-config.log

drivers/net/ethernet/jme.o: warning: objtool: jme_check_link() falls through to next function jme_powersave_phy()
	x86_64-alpine-config.log
	x86_64-opensuse-config.log

drivers/net/ethernet/mellanox/mlx5/core/en/params.o: warning: objtool: mlx5e_mpwrq_max_log_rq_size() falls through to next function mlx5e_get_linear_rq_headroom()
	x86_64-alpine-config.log

drivers/net/ethernet/mellanox/mlx5/core/en/params.o: warning: objtool: mlx5e_mpwrq_mtts_per_wqe() falls through to next function mlx5e_mpwrq_max_num_entries()
	x86_64-alpine-config.log

fs/bcachefs/btree_update_interior.o: warning: objtool: bch2_btree_split_leaf() falls through to next function bch2_btree_update_start()
	x86_64-alpine-config.log

drivers/gpu/drm/amd/amdgpu/amdgpu.o: warning: objtool: dc_fixpt_recip() falls through to next function dc_fixpt_sinc()
	x86_64-archlinux-config.log
	x86_64-debian-config.log
	x86_64-fedora-config.log
	x86_64-opensuse-config.log

drivers/gpu/drm/amd/amdgpu/amdgpu.o: warning: objtool: spl_fixpt_recip() falls through to next function spl_fixpt_sinc()
	x86_64-archlinux-config.log
	x86_64-debian-config.log
	x86_64-fedora-config.log
	x86_64-opensuse-config.log

drivers/media/i2c/ccs/ccs.o: warning: objtool: ccs_set_selection() falls through to next function ccs_propagate()
	x86_64-archlinux-config.log
	x86_64-fedora-config.log
	x86_64-opensuse-config.log

drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.o: warning: objtool: mlx5e_mpwrq_max_log_rq_size() falls through to next function mlx5e_get_linear_rq_headroom()
	x86_64-archlinux-config.log
	x86_64-debian-config.log
	x86_64-fedora-config.log
	x86_64-opensuse-config.log

drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.o: warning: objtool: mlx5e_mpwrq_mtts_per_wqe() falls through to next function mlx5e_mpwrq_max_num_entries()
	x86_64-archlinux-config.log
	x86_64-debian-config.log
	x86_64-fedora-config.log
	x86_64-opensuse-config.log

drivers/media/pci/solo6x10/solo6x10.o: warning: objtool: tw28_set_ctrl_val() falls through to next function tw28_get_ctrl_val()
	x86_64-fedora-config.log

drivers/misc/lkdtm/lkdtm.o: warning: objtool: execute_location+0x4f: relocation to !ENDBR: .text+0x11a8
	x86_64-opensuse-config.log

-----------------------------------------------

I know the fixpt_recip warnings from amdgpu.o have a patch on the
mailing list and I think the LoongArch folks are aware of the ones in
their builds.

LTO does definitely give the compiler more ability to find and optimize
around undefined behavior and that does make things more difficult to
triage. Sanitizers muck things about too :/

> But I can also envisage a world where that creates exactly as much
> work for you, just introducing Kconfig hackery for no reason!

Such is the nature of such changes. It is not that big of a deal for us
to work around in the short term but it would still need to be addressed
pretty quickly at that point.

> > If exposing this to the world feels too premature, maybe the flag could
> > be added then have a make variable like OBJTOOL_FLAGS to allow a
> > developer to pass it through if they wish?
> 
> Yeah, that would definitely be a reasonable start.
> 
> I'll wait and see if Josh has any additional thoughts.

Sounds good, thanks again for bringing this up.

Cheers,
Nathan

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings
  2025-01-31 20:49         ` Nathan Chancellor
@ 2025-02-06 15:05           ` Brendan Jackman
  2025-02-06 17:10             ` Nathan Chancellor
  0 siblings, 1 reply; 15+ messages in thread
From: Brendan Jackman @ 2025-02-06 15:05 UTC (permalink / raw)
  To: Nathan Chancellor
  Cc: Josh Poimboeuf, Peter Zijlstra, Andrew Morton, Masahiro Yamada,
	Nicolas Schier, linux-kernel, linux-kbuild

OK, it would be interesting to spend a couple of hours staring at
these errors and see if I can get a feel for the overal picture..

Also, now that I think about it I'm a bit embarrassed I didn't try
building allmodconfig before sending this series (maybe I had
forgotten it exists?)! Sorry about that :)

On Fri, 31 Jan 2025 at 21:49, Nathan Chancellor <nathan@kernel.org> wrote:
> > But I can also envisage a world where that creates exactly as much
> > work for you, just introducing Kconfig hackery for no reason!
>
> Such is the nature of such changes. It is not that big of a deal for us
> to work around in the short term but it would still need to be addressed
> pretty quickly at that point.

I can't quite parse what you're getting at here - is this an opinion
about the idea to depend on !COMPILE_TEST, and if so are you in favour
of it? My thinking is that if it defaults n and isn't in allmodconfig,
the only people who will turn it on are those who actively care about
clean objtool for their build. Which.. isn't really what we want long
term, but it's better than not having the option at all and is already
a step in the direction of something that can act as a "ratchet".

If not, I'll go ahead with the OBJTOOL_FLAGS thing. (Which is still a
nice step in that direction).

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings
  2025-02-06 15:05           ` Brendan Jackman
@ 2025-02-06 17:10             ` Nathan Chancellor
  2025-02-07  2:51               ` Josh Poimboeuf
  0 siblings, 1 reply; 15+ messages in thread
From: Nathan Chancellor @ 2025-02-06 17:10 UTC (permalink / raw)
  To: Brendan Jackman
  Cc: Josh Poimboeuf, Peter Zijlstra, Andrew Morton, Masahiro Yamada,
	Nicolas Schier, linux-kernel, linux-kbuild

On Thu, Feb 06, 2025 at 04:05:01PM +0100, Brendan Jackman wrote:
> OK, it would be interesting to spend a couple of hours staring at
> these errors and see if I can get a feel for the overal picture..
> 
> Also, now that I think about it I'm a bit embarrassed I didn't try
> building allmodconfig before sending this series (maybe I had
> forgotten it exists?)! Sorry about that :)
> 
> On Fri, 31 Jan 2025 at 21:49, Nathan Chancellor <nathan@kernel.org> wrote:
> > > But I can also envisage a world where that creates exactly as much
> > > work for you, just introducing Kconfig hackery for no reason!
> >
> > Such is the nature of such changes. It is not that big of a deal for us
> > to work around in the short term but it would still need to be addressed
> > pretty quickly at that point.
> 
> I can't quite parse what you're getting at here - is this an opinion
> about the idea to depend on !COMPILE_TEST, and if so are you in favour
> of it?

Sorry, that was more of a comment around having to disable that
configuration for builds such as allmodconfig if necessary to keep our
builds green. We can do it but that is not a long term solution because
we are not the only ones building allmodconfig with clang and we cannot
just tell everyone to disable it.

> My thinking is that if it defaults n and isn't in allmodconfig, the
> only people who will turn it on are those who actively care about
> clean objtool for their build. Which.. isn't really what we want long
> term, but it's better than not having the option at all and is already
> a step in the direction of something that can act as a "ratchet".

Right, I think gating on '!COMPILE_TEST' would not be a terrible way to
introduce it. We would definitely want to remove that dependency as
soon as possible because we want compile testers to be qble to find
these problems and have them be noticeable but it should make the
introduction of CONFIG_OBJTOOL_WERROR less disruptive.

> If not, I'll go ahead with the OBJTOOL_FLAGS thing. (Which is still a
> nice step in that direction).

This may still be worth doing because with the aforementioned
dependency, it would make it difficult to test with --Werror for
COMPILE_TEST configurations.  Maybe Josh or Peter have other opinions
though.

Cheers,
Nathan

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings
  2025-02-06 17:10             ` Nathan Chancellor
@ 2025-02-07  2:51               ` Josh Poimboeuf
  2025-02-07 10:16                 ` Brendan Jackman
  2025-02-07 21:41                 ` Nathan Chancellor
  0 siblings, 2 replies; 15+ messages in thread
From: Josh Poimboeuf @ 2025-02-07  2:51 UTC (permalink / raw)
  To: Nathan Chancellor
  Cc: Brendan Jackman, Peter Zijlstra, Andrew Morton, Masahiro Yamada,
	Nicolas Schier, linux-kernel, linux-kbuild

On Thu, Feb 06, 2025 at 10:10:36AM -0700, Nathan Chancellor wrote:
> Right, I think gating on '!COMPILE_TEST' would not be a terrible way to
> introduce it. We would definitely want to remove that dependency as
> soon as possible because we want compile testers to be qble to find
> these problems and have them be noticeable but it should make the
> introduction of CONFIG_OBJTOOL_WERROR less disruptive.

I want to get CONFIG_OBJTOOL_WERROR merged soon.  I'm working on some
other patches to go along with it that will hopefully ease some of the
pain.  I'll post those soon and then hopefully we can get it into
linux-next.

I didn't quite follow the OBJTOOL_FLAGS idea.  We already have
OBJTOOL_ARGS which allows adding arguments (though not removing them),
was it mean to be something like that?

I agree we might want to ease into the pool with !COMPILE_TEST.

-- 
Josh

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings
  2025-02-07  2:51               ` Josh Poimboeuf
@ 2025-02-07 10:16                 ` Brendan Jackman
  2025-02-07 21:41                 ` Nathan Chancellor
  1 sibling, 0 replies; 15+ messages in thread
From: Brendan Jackman @ 2025-02-07 10:16 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Nathan Chancellor, Peter Zijlstra, Andrew Morton, Masahiro Yamada,
	Nicolas Schier, linux-kernel, linux-kbuild

On Fri, 7 Feb 2025 at 03:51, Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> I didn't quite follow the OBJTOOL_FLAGS idea.  We already have
> OBJTOOL_ARGS which allows adding arguments (though not removing them),
> was it mean to be something like that?

Oh. Yeah, exactly that. Nothing to do on this point then.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings
  2025-02-07  2:51               ` Josh Poimboeuf
  2025-02-07 10:16                 ` Brendan Jackman
@ 2025-02-07 21:41                 ` Nathan Chancellor
  1 sibling, 0 replies; 15+ messages in thread
From: Nathan Chancellor @ 2025-02-07 21:41 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Brendan Jackman, Peter Zijlstra, Andrew Morton, Masahiro Yamada,
	Nicolas Schier, linux-kernel, linux-kbuild

On Thu, Feb 06, 2025 at 06:51:27PM -0800, Josh Poimboeuf wrote:
> On Thu, Feb 06, 2025 at 10:10:36AM -0700, Nathan Chancellor wrote:
> > Right, I think gating on '!COMPILE_TEST' would not be a terrible way to
> > introduce it. We would definitely want to remove that dependency as
> > soon as possible because we want compile testers to be qble to find
> > these problems and have them be noticeable but it should make the
> > introduction of CONFIG_OBJTOOL_WERROR less disruptive.
> 
> I want to get CONFIG_OBJTOOL_WERROR merged soon.  I'm working on some
> other patches to go along with it that will hopefully ease some of the
> pain.  I'll post those soon and then hopefully we can get it into
> linux-next.

Sounds good to me, getting it into linux-next will give us a good idea
of how disruptive it may be.

> I didn't quite follow the OBJTOOL_FLAGS idea.  We already have
> OBJTOOL_ARGS which allows adding arguments (though not removing them),
> was it mean to be something like that?

Yes, I should have prefaced "if it does not already exist" since I did
not realize that there was already support for adding to objtool
arguments via an environment/make variable already.

Cheers,
Nathan

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2025-02-07 21:41 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-13 14:05 [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings Brendan Jackman
2025-01-13 14:05 ` [PATCH v3 1/2] objtool: Add --Werror Brendan Jackman
2025-01-14 17:24   ` Nathan Chancellor
2025-01-14 18:17     ` Josh Poimboeuf
2025-01-13 14:05 ` [PATCH v3 2/2] kbuild: Add option to fail build on vmlinux objtool issues Brendan Jackman
2025-01-14  0:14 ` [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings Josh Poimboeuf
2025-01-30 15:55   ` Brendan Jackman
2025-01-30 18:30     ` Nathan Chancellor
2025-01-31 10:44       ` Brendan Jackman
2025-01-31 20:49         ` Nathan Chancellor
2025-02-06 15:05           ` Brendan Jackman
2025-02-06 17:10             ` Nathan Chancellor
2025-02-07  2:51               ` Josh Poimboeuf
2025-02-07 10:16                 ` Brendan Jackman
2025-02-07 21:41                 ` Nathan Chancellor

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox