Re: [PATCH v14 18/30] tracing: Check for undefined symbols in simple_ring_buffer

[Vincent Donnefort]

On Thu, Mar 12, 2026 at 08:55:14AM +0000, Vincent Donnefort wrote:
> On Wed, Mar 11, 2026 at 03:18:16PM -0700, Nathan Chancellor wrote:
> > Hi Vincent,
> > 
> > On Mon, Mar 09, 2026 at 04:25:04PM +0000, Vincent Donnefort wrote:
> > > The simple_ring_buffer implementation must remain simple enough to be
> > > used by the pKVM hypervisor. Prevent the object build if unresolved
> > > symbols are found.
> > > 
> > > Reviewed-by: Steven Rostedt (Google) <rostedt@xxxxxxxxxxx>
> > > Signed-off-by: Vincent Donnefort <vdonnefort@xxxxxxxxxx>
> > > 
> > > diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
> > > index d106beca8d7f..3182e1bc1cf7 100644
> > > --- a/kernel/trace/Makefile
> > > +++ b/kernel/trace/Makefile
> > > @@ -132,4 +132,20 @@ obj-$(CONFIG_TRACE_REMOTE) += trace_remote.o
> > >  obj-$(CONFIG_SIMPLE_RING_BUFFER) += simple_ring_buffer.o
> > >  obj-$(CONFIG_TRACE_REMOTE_TEST) += remote_test.o
> > >  
> > > +#
> > > +# simple_ring_buffer is used by the pKVM hypervisor which does not have access
> > > +# to all kernel symbols. Fail the build if forbidden symbols are found.
> > > +#
> > > +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 := $(addprefix -e , $(UNDEFINED_ALLOWLIST))
> > > +
> > > +quiet_cmd_check_undefined = NM      $<
> > > +      cmd_check_undefined = test -z "`$(NM) -u $< | grep -v $(UNDEFINED_ALLOWLIST)`"
> > 
> > This check triggers when building allmodconfig targeting arm, arm64,
> > powerpc, and x86_64 (at least, I did not test more at the moment) with
> > clang. If this is a hard failure, this really needs to print something
> > out to the developer/user to help them debug off the bat, versus having
> > to manually dig the $(NM) command out from the .cmd file or V=1. I came
> > up with
> > 
> > diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
> > index 3182e1bc1cf7..c725b06876bc 100644
> > --- a/kernel/trace/Makefile
> > +++ b/kernel/trace/Makefile
> > @@ -141,7 +141,13 @@ UNDEFINED_ALLOWLIST += __stack_chk_fail stackleak_track_stack __ref_stack __sani
> >  UNDEFINED_ALLOWLIST := $(addprefix -e , $(UNDEFINED_ALLOWLIST))
> >  
> >  quiet_cmd_check_undefined = NM      $<
> > -      cmd_check_undefined = test -z "`$(NM) -u $< | grep -v $(UNDEFINED_ALLOWLIST)`"
> > +      cmd_check_undefined = \
> > +          undefsyms=$$($(NM) -u $< | grep -v $(UNDEFINED_ALLOWLIST) || true); \
> > +          if [ -n "$$undefsyms" ]; then \
> > +              echo "Unexpected symbols in $<:" >&2; \
> > +              echo "$$undefsyms" >&2; \
> > +              false; \
> > +          fi
> >  
> >  $(obj)/%.o.checked: $(obj)/%.o FORCE
> >  	$(call if_changed,check_undefined)
> > --
> > 
> > which prints
> > 
> >   Unexpected symbols in kernel/trace/simple_ring_buffer.o:
> >                    U llvm_gcda_emit_arcs
> >                    U llvm_gcda_emit_function
> >                    U llvm_gcda_end_file
> >                    U llvm_gcda_start_file
> >                    U llvm_gcda_summary_info
> >                    U llvm_gcov_init
> > 
> > for arm64, which makes sense since these are LLVM specific GCOV symbols,
> > so they should probably get the same treatment as the other ones:
> > 
> > diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
> > index c725b06876bc..d464e3aa5bdd 100644
> > --- a/kernel/trace/Makefile
> > +++ b/kernel/trace/Makefile
> > @@ -136,8 +136,8 @@ obj-$(CONFIG_TRACE_REMOTE_TEST) += remote_test.o
> >  # simple_ring_buffer is used by the pKVM hypervisor which does not have access
> >  # to all kernel symbols. Fail the build if forbidden symbols are found.
> >  #
> > -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 := memset alt_cb_patch_nops __x86 __ubsan __asan __kasan __gcov llvm_gcda llvm_gcov
> > +UNDEFINED_ALLOWLIST += __aeabi_unwind __stack_chk_fail stackleak_track_stack __ref_stack __sanitizer
> >  UNDEFINED_ALLOWLIST := $(addprefix -e , $(UNDEFINED_ALLOWLIST))
> >  
> >  quiet_cmd_check_undefined = NM      $<
> > --
> > 
> > For x86_64, I see
> > 
> >   Unexpected symbols in kernel/trace/simple_ring_buffer.o:
> >                    U __clear_pages_unrolled
> >                    U __memmove
> >                    U copy_page
> > 
> > which comes from the use of KCFI_ADDRESSABLE(), since allmodconfig has
> > CONFIG_CFI=y.
> > 
> > For powerpc (with both clang and GCC), I see
> > 
> >   Unexpected symbols in kernel/trace/simple_ring_buffer.o:
> >                    U .TOC.
> > 
> > For arm (with both clang and GCC), I see
> > 
> >   Unexpected symbols in kernel/trace/simple_ring_buffer.o:
> >            U __stack_chk_guard
> >            U warn_slowpath_fmt
> > 
> > Presumably adding all of those should be fine as well?
> > 
> > diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
> > index d464e3aa5bdd..4f120cb8c79c 100644
> > --- a/kernel/trace/Makefile
> > +++ b/kernel/trace/Makefile
> > @@ -137,7 +137,8 @@ obj-$(CONFIG_TRACE_REMOTE_TEST) += remote_test.o
> >  # to all kernel symbols. Fail the build if forbidden symbols are found.
> >  #
> >  UNDEFINED_ALLOWLIST := memset alt_cb_patch_nops __x86 __ubsan __asan __kasan __gcov llvm_gcda llvm_gcov
> > -UNDEFINED_ALLOWLIST += __aeabi_unwind __stack_chk_fail stackleak_track_stack __ref_stack __sanitizer
> > +UNDEFINED_ALLOWLIST += __aeabi_unwind __stack_chk_fail __stack_chk_guard stackleak_track_stack __ref_stack __sanitizer
> > +UNDEFINED_ALLOWLIST += \.TOC\. __clear_pages_unrolled __memmove copy_page warn_slowpath_fmt
> >  UNDEFINED_ALLOWLIST := $(addprefix -e , $(UNDEFINED_ALLOWLIST))
> >  
> >  quiet_cmd_check_undefined = NM      $<
> > --
> > 
> > I don't mind sending a series for these, I just wanted to make sure I
> > was reasoning about everything correctly.
> 
> Yes this is all fine. If you have something already, please send it. Meanwhile, I'll try
> something a bit more durable. 
> 
> Thanks,
> Vincent

In the end to unblock linux-next I have already sent an updated list of symbols.
However feel free to send the logging bit, that is surely useful.

> 
> > 
> > Cheers,
> > Nathan