On Fri, Mar 06, 2026 at 11:40:21AM -0800, Yonghong Song wrote:
>
>
> On 3/6/26 10:32 AM, Josh Poimboeuf wrote:
> > On Thu, Mar 05, 2026 at 07:43:25PM -0800, Yonghong Song wrote:
> > > The current clang thin-lto build often produces lots of symbols with
> > > suffix. The following is a partial list of such function call symbols:
> > > ...
> > > ethnl_module_fw_flash_ntf.llvm.7631589765585346066
> > > __nf_conntrack_alloc.llvm.6438426151906658917
> > > tcp_can_early_drop.llvm.11937612064648250727
> > > tcp_print_conntrack.llvm.11937612064648250727
> > > ...
> > >
> > > In my particular build with current bpf-next, the number of
> > > '*.llvm.<hash>'
> > > function calls is 1212. Such symbols make kernel live patching
> > > difficult since
> > > - a minor code change will change the hash and then the '*.llvm.<hash>'
> > > symbol becomes another one with a different hash or no hash, and
> > > - a previous source-level symbol may become an one with suffix after
> > > live
> > > patching code.
> > >
> > > In [1], Song Liu suggested to reduce the number of '*.llvm.<hash>'
> > > functions
> > > to make live patch easier. In respond of this, I implemented this
> > > in llvm ([2]). The same thin-lto build with [2] only has two symbols with
> > > suffix:
> > > m_stop.llvm.14460341347352036579
> > > m_next.llvm.14460341347352036579
> > > This should make live patch much easier.
> > >
> > > To support suffix symbol reduction, a new config
> > > LTO_CLANG_THIN_SUFFIX_REDUCTION
> > > is introduced and the config depends on thin-lto and llvm23 or higher.
> > >
> > > Two lld flags are necessary to enable this feature in kernel:
> > > - Flag '--lto-whole-program-visibility' is needed as it ensures that
> > > all
> > > modules are available in the same process, which is true for
> > > kernel at
> > > thin-lto lld.
> > > - Flag '-mllvm -always-rename-promoted-locals=false' is needed to
> > > enable
> > > suffix reduction. Currently in llvm [1], only process mode is
> > > supported.
> > > There is another distributed mode (across different processes or
> > > even
> > > different machines) which is not supported yet ([2]).
> > >
> > > [1] https://lpc.events/event/19/contributions/2212
> > > [2] https://github.com/llvm/llvm-project/pull/178587
> > >
> > > Signed-off-by: Yonghong Song <[email protected]>
> > > ---
> > > Makefile | 3 +++
> > > arch/Kconfig | 15 +++++++++++++++
> > > 2 files changed, 18 insertions(+)
> > >
> > > diff --git a/Makefile b/Makefile
> > > index e944c6e71e81..9d6033595615 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -1034,6 +1034,9 @@ endif
> > > ifdef CONFIG_LTO_CLANG
> > > ifdef CONFIG_LTO_CLANG_THIN
> > > CC_FLAGS_LTO := -flto=thin -fsplit-lto-unit
> > > +ifdef CONFIG_LTO_CLANG_THIN_SUFFIX_REDUCTION
> > > +KBUILD_LDFLAGS += --lto-whole-program-visibility -mllvm
> > > -always-rename-promoted-locals=false
> > > +endif
> > > else
> > > CC_FLAGS_LTO := -flto
> > > endif
> > > diff --git a/arch/Kconfig b/arch/Kconfig
> > > index 102ddbd4298e..e1db64a3284e 100644
> > > --- a/arch/Kconfig
> > > +++ b/arch/Kconfig
> > > @@ -861,8 +861,23 @@ config LTO_CLANG_THIN
> > > https://clang.llvm.org/docs/ThinLTO.html
> > > If unsure, say Y.
> > > +
> > > endchoice
> > > +config LTO_CLANG_THIN_SUFFIX_REDUCTION
> > > + bool "Clang ThinLTO Suffix Reduction (EXPERIMENTAL)"
> > > + depends on LTO_CLANG_THIN
> > > + depends on CLANG_VERSION >= 230000
> > > + default y
> > > + help
> > > + This option allows to reduce the number of symbols with
> > > + '.llvm.<hash' suffixes. This can help KLP (kernel living
> > > + patch) as symbol name can stay stable in most cases.
> > > +
> > > + See https://github.com/llvm/llvm-project/pull/178587
> > > +
> > > + If unsure, say N.
> > > +
> > Thanks! Would there be any downsides to enabling this feature
> > unconditionally in the kernel when the compiler supports it?
>
> The only downside is for the following case:
>
> C file: static function foo()
> Asm file: global function foo()
>
> The thin-lto will collect all C files and with the above llvm patch,
> the static function foo() may be promoted to global function foo()
> if there is no other pre-existing global function foo() in all C files.
>
> In such cases, there will be a conflict since
> there are two global function foo() (one from C file, another from Asm file).
> In such cases, the build will fail.
>
> How do you think we could hit such issues in linux kernel?
> Maybe should have default no for the new config?
>
> I think the chance should be very low. The following is a grab for x86
> for global symbols in asm code:
>
> [~/work/others/linux/arch/x86 (master)]$ egrep -r globl
There are actually quite a bit more than that, see SYM_CODE_START:
$ git grep 'SYM_CODE_START(' |wc -l
169
But still, I agree the chance of a conflict would be very low. And
global assembly functions tend to be rather uniquely named.
> Maybe we could collect all global symbols in asm codes before lld,
> and then we add an option in lld to feed those global symbols (with a file?),
> then we can be sure there won't be any conflict?
That wouldn't be worth the effort in my opinion.
I think we should just unconditionally enable
-always-rename-promoted-locals=false when it's available. While that
will implicitly enforce that global asm functions be uniquely named
across the tree, I don't see that as a problem. In the rare case of a
conflict, we can just rename the function.
--
Josh
