* [PATCH 2/3] tracing: add more symbols to whitelist [not found] <20260312123601.625063-1-arnd@kernel.org> @ 2026-03-12 12:35 ` Arnd Bergmann 2026-03-12 13:40 ` Vincent Donnefort 0 siblings, 1 reply; 5+ messages in thread From: Arnd Bergmann @ 2026-03-12 12:35 UTC (permalink / raw) To: Vincent Donnefort, Marc Zyngier Cc: Steven Rostedt, Oliver Upton, Catalin Marinas, Will Deacon, Arnd Bergmann, Masami Hiramatsu, Mathieu Desnoyers, linux-kernel, linux-trace-kernel From: Arnd Bergmann <arnd@arndb.de> Randconfig builds show a number of cryptic build errors from hitting undefined symbols in simple_ring_buffer.o: make[7]: *** [/home/arnd/arm-soc/kernel/trace/Makefile:147: kernel/trace/simple_ring_buffer.o.checked] Error 1 These happen with CONFIG_TRACE_BRANCH_PROFILING, CONFIG_KASAN_HW_TAGS, CONFIG_STACKPROTECTOR, CONFIG_DEBUG_IRQFLAGS and indirectly from WARN_ON(). Add exceptions for each one that I have hit so far on arm64, x86_64 and arm randconfig builds. Other architectures likely hit additional ones, so it would be nice to produce a little more verbose output that include the name of the missing symbols directly. Fixes: a717943d8ecc ("tracing: Check for undefined symbols in simple_ring_buffer") Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- kernel/trace/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile index 3182e1bc1cf7..e3f8d6e619d2 100644 --- a/kernel/trace/Makefile +++ b/kernel/trace/Makefile @@ -138,6 +138,8 @@ obj-$(CONFIG_TRACE_REMOTE_TEST) += remote_test.o # UNDEFINED_ALLOWLIST := memset alt_cb_patch_nops __x86 __ubsan __asan __kasan __gcov __aeabi_unwind UNDEFINED_ALLOWLIST += __stack_chk_fail stackleak_track_stack __ref_stack __sanitizer +UNDEFINED_ALLOWLIST += ftrace_likely_update __hwasan_load __hwasan_store __hwasan_tag_memory +UNDEFINED_ALLOWLIST += warn_bogus_irq_restore warn_slowpath_fmt __stack_chk_guard UNDEFINED_ALLOWLIST := $(addprefix -e , $(UNDEFINED_ALLOWLIST)) quiet_cmd_check_undefined = NM $< -- 2.39.5 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH 2/3] tracing: add more symbols to whitelist 2026-03-12 12:35 ` [PATCH 2/3] tracing: add more symbols to whitelist Arnd Bergmann @ 2026-03-12 13:40 ` Vincent Donnefort 2026-03-12 14:37 ` Arnd Bergmann 0 siblings, 1 reply; 5+ messages in thread From: Vincent Donnefort @ 2026-03-12 13:40 UTC (permalink / raw) To: Arnd Bergmann Cc: Marc Zyngier, Steven Rostedt, Oliver Upton, Catalin Marinas, Will Deacon, Arnd Bergmann, Masami Hiramatsu, Mathieu Desnoyers, linux-kernel, linux-trace-kernel On Thu, Mar 12, 2026 at 01:35:43PM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@arndb.de> > > Randconfig builds show a number of cryptic build errors from > hitting undefined symbols in simple_ring_buffer.o: > > make[7]: *** [/home/arnd/arm-soc/kernel/trace/Makefile:147: kernel/trace/simple_ring_buffer.o.checked] Error 1 > > These happen with CONFIG_TRACE_BRANCH_PROFILING, CONFIG_KASAN_HW_TAGS, > CONFIG_STACKPROTECTOR, CONFIG_DEBUG_IRQFLAGS and indirectly from WARN_ON(). > > Add exceptions for each one that I have hit so far on arm64, x86_64 and arm > randconfig builds. > > Other architectures likely hit additional ones, so it would be nice > to produce a little more verbose output that include the name of the > missing symbols directly. > > Fixes: a717943d8ecc ("tracing: Check for undefined symbols in simple_ring_buffer") > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > kernel/trace/Makefile | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile > index 3182e1bc1cf7..e3f8d6e619d2 100644 > --- a/kernel/trace/Makefile > +++ b/kernel/trace/Makefile > @@ -138,6 +138,8 @@ obj-$(CONFIG_TRACE_REMOTE_TEST) += remote_test.o > # > UNDEFINED_ALLOWLIST := memset alt_cb_patch_nops __x86 __ubsan __asan __kasan __gcov __aeabi_unwind > UNDEFINED_ALLOWLIST += __stack_chk_fail stackleak_track_stack __ref_stack __sanitizer > +UNDEFINED_ALLOWLIST += ftrace_likely_update __hwasan_load __hwasan_store __hwasan_tag_memory > +UNDEFINED_ALLOWLIST += warn_bogus_irq_restore warn_slowpath_fmt __stack_chk_guard > UNDEFINED_ALLOWLIST := $(addprefix -e , $(UNDEFINED_ALLOWLIST)) > > quiet_cmd_check_undefined = NM $< > -- > 2.39.5 > Thanks for the patch. Most of those ones are covered here https://lore.kernel.org/all/20260312113535.2213350-1-vdonnefort@google.com/. This should fix allmodconfig. For the ones not covered, I'm working on a follow-up patch using a different approach which should fix them. I'll be able to share it today or tomorrow. Not sure if we want to take this temporarily? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 2/3] tracing: add more symbols to whitelist 2026-03-12 13:40 ` Vincent Donnefort @ 2026-03-12 14:37 ` Arnd Bergmann 2026-03-12 15:21 ` Marc Zyngier 0 siblings, 1 reply; 5+ messages in thread From: Arnd Bergmann @ 2026-03-12 14:37 UTC (permalink / raw) To: Vincent Donnefort, Arnd Bergmann Cc: Marc Zyngier, Steven Rostedt, Oliver Upton, Catalin Marinas, Will Deacon, Masami Hiramatsu, Mathieu Desnoyers, linux-kernel, linux-trace-kernel On Thu, Mar 12, 2026, at 14:40, Vincent Donnefort wrote: > On Thu, Mar 12, 2026 at 01:35:43PM +0100, Arnd Bergmann wrote: >> diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile >> +UNDEFINED_ALLOWLIST += ftrace_likely_update __hwasan_load __hwasan_store __hwasan_tag_memory >> +UNDEFINED_ALLOWLIST += warn_bogus_irq_restore warn_slowpath_fmt __stack_chk_guard > > Thanks for the patch. > > Most of those ones are covered here > https://lore.kernel.org/all/20260312113535.2213350-1-vdonnefort@google.com/. > > This should fix allmodconfig. The ones I see in that patch look entirely different from the ones I found. > For the ones not covered, I'm working on a follow-up patch using a different > approach which should fix them. I'll be able to share it today or tomorrow. Not > sure if we want to take this temporarily? I can wait, my randconfig setup has my patch applied locally for now, but I've only fixed the ones I saw on three architectures with gcc-16.0.1, while Nathan's list seems to be mostly for clang specific symbols. A lot of them also don't show up in allmodconfig builds, only after a larger number of randconfig configurations. Arnd ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 2/3] tracing: add more symbols to whitelist 2026-03-12 14:37 ` Arnd Bergmann @ 2026-03-12 15:21 ` Marc Zyngier 2026-03-12 15:37 ` Arnd Bergmann 0 siblings, 1 reply; 5+ messages in thread From: Marc Zyngier @ 2026-03-12 15:21 UTC (permalink / raw) To: Arnd Bergmann Cc: Vincent Donnefort, Arnd Bergmann, Steven Rostedt, Oliver Upton, Catalin Marinas, Will Deacon, Masami Hiramatsu, Mathieu Desnoyers, linux-kernel, linux-trace-kernel On Thu, 12 Mar 2026 14:37:50 +0000, "Arnd Bergmann" <arnd@arndb.de> wrote: > > On Thu, Mar 12, 2026, at 14:40, Vincent Donnefort wrote: > > On Thu, Mar 12, 2026 at 01:35:43PM +0100, Arnd Bergmann wrote: > >> diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile > > >> +UNDEFINED_ALLOWLIST += ftrace_likely_update __hwasan_load __hwasan_store __hwasan_tag_memory > >> +UNDEFINED_ALLOWLIST += warn_bogus_irq_restore warn_slowpath_fmt __stack_chk_guard > > > > > Thanks for the patch. > > > > Most of those ones are covered here > > https://lore.kernel.org/all/20260312113535.2213350-1-vdonnefort@google.com/. > > > > This should fix allmodconfig. > > The ones I see in that patch look entirely different from the ones > I found. > > > For the ones not covered, I'm working on a follow-up patch using a different > > approach which should fix them. I'll be able to share it today or tomorrow. Not > > sure if we want to take this temporarily? > > I can wait, my randconfig setup has my patch applied locally for now, > but I've only fixed the ones I saw on three architectures with gcc-16.0.1, > while Nathan's list seems to be mostly for clang specific symbols. > > A lot of them also don't show up in allmodconfig builds, only after a > larger number of randconfig configurations. I've decided to take this patch anyway, on top of Vincent's. Should a more generic solution arise, I can always drop both. Thanks, M. -- Without deviation from the norm, progress is not possible. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 2/3] tracing: add more symbols to whitelist 2026-03-12 15:21 ` Marc Zyngier @ 2026-03-12 15:37 ` Arnd Bergmann 0 siblings, 0 replies; 5+ messages in thread From: Arnd Bergmann @ 2026-03-12 15:37 UTC (permalink / raw) To: Marc Zyngier Cc: Vincent Donnefort, Arnd Bergmann, Steven Rostedt, Oliver Upton, Catalin Marinas, Will Deacon, Masami Hiramatsu, Mathieu Desnoyers, linux-kernel, linux-trace-kernel On Thu, Mar 12, 2026, at 16:21, Marc Zyngier wrote: > > I've decided to take this patch anyway, on top of Vincent's. Should a > more generic solution arise, I can always drop both. > Ok, thanks! FWIW, I came across two additional ones by now, and will keep running more tests to see what else comes up: --- a/kernel/trace/Makefile +++ b/kernel/trace/Makefile @@ -140,6 +140,7 @@ UNDEFINED_ALLOWLIST := memset alt_cb_patch_nops __x86 __ubsan __asan __kasan __g UNDEFINED_ALLOWLIST += __stack_chk_fail stackleak_track_stack __ref_stack __sanitizer UNDEFINED_ALLOWLIST += ftrace_likely_update __hwasan_load __hwasan_store __hwasan_tag_memory UNDEFINED_ALLOWLIST += warn_bogus_irq_restore warn_slowpath_fmt __stack_chk_guard +UNDEFINED_ALLOWLIST += __kcsan __tsan UNDEFINED_ALLOWLIST := $(addprefix -e , $(UNDEFINED_ALLOWLIST)) quiet_cmd_check_undefined = NM $< Arnd ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-03-12 15:37 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260312123601.625063-1-arnd@kernel.org>
2026-03-12 12:35 ` [PATCH 2/3] tracing: add more symbols to whitelist Arnd Bergmann
2026-03-12 13:40 ` Vincent Donnefort
2026-03-12 14:37 ` Arnd Bergmann
2026-03-12 15:21 ` Marc Zyngier
2026-03-12 15:37 ` Arnd Bergmann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox