Re: [PATCH] printf: mark errptr() noinline

Tamir Duberstein
2026-04-06T15:22:16Z

On Mon, Apr 6, 2026 at 11:14 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Sun, 05 Apr 2026 13:31:50 -0400
> Tamir Duberstein <tamird@kernel.org> wrote:
>
> > Old GCC can miscompile printf_kunit's errptr() test when branch
> > profiling is enabled. BUILD_BUG_ON(IS_ERR(PTR)) is a constant false
> > expression, but CONFIG_TRACE_BRANCH_PROFILING and
> > CONFIG_PROFILE_ALL_BRANCHES make the IS_ERR() path side-effectful.
> > GCC's IPA splitter can then outline the cold assert arm into
> > errptr.part.* and leave that clone with an unconditional
> > __compiletime_assert_*() call, causing a false build failure.
> >
> > This started showing up after test_hashed() became a macro and moved its
> > local buffer into errptr(), which changed GCC's inlining and splitting
> > decisions enough to expose the compiler bug.
> >
> > Mark errptr() noinline to keep it out of that buggy IPA path while
> > preserving the BUILD_BUG_ON(IS_ERR(PTR)) check and the macro-based
> > printf argument checking.
> >
> > Fixes: 9bfa52dac27a ("printf: convert test_hashed into macro")
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202604030636.NqjaJvYp-lkp@intel.com/
> > Signed-off-by: Tamir Duberstein <tamird@kernel.org>
>
> Another solution which I would be fine with is:
>
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index e130da35808f..c07e8eadfdd0 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -692,6 +692,7 @@ config PROFILE_ANNOTATED_BRANCHES
> config PROFILE_ALL_BRANCHES
> bool "Profile all if conditionals" if !FORTIFY_SOURCE
> select TRACE_BRANCH_PROFILING
> + depends on !KUNIT
> help
> This tracer profiles all branch conditions. Every if ()
> taken in the kernel is recorded whether it hit or miss.
>
>
> -- Steve

Thanks Steve. IMO that is a very big hammer and not warranted in this
case. There's been talk of encouraging distros to enable CONFIG_KUNIT
by default [0], which would probably interact poorly with the change
you propose.

Link: https://lore.kernel.org/all/CABVgOS=KZrM2dWyp1HzVS0zh7vquLxmTY2T2Ti53DQADrW+sJg@mail.gmail.com/
[0]