linux-kernel - Re: clang thin-lto not working for aarch64 for v6.13

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPhsuW4dC-Wma8EGBxkbftgRtmZohojqhvsixHQ3C4MNrH1+9w@mail.gmail.com>
Date: Mon, 27 Jan 2025 09:50:15 -0800
From: Song Liu <song@...nel.org>
To: Yonghong Song <yonghong.song@...ux.dev>, Masahiro Yamada <masahiroy@...nel.org>
Cc: Nathan Chancellor <nathan@...nel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: clang thin-lto not working for aarch64 for v6.13

On Sun, Jan 26, 2025 at 7:48 PM Yonghong Song <yonghong.song@...ux.dev> wrote:
>
> Hi, Masahiro,
>
> We are trying 6.13 kernel and found that for aarch64 thinlto not
> working. For example, for kernel/bpf/syscall.o, the compilation flags
> from .syscall.o.cmd are savedcmd_kernel/bpf/syscall.o := clang
> -Wp,-MMD,kernel/bpf/.syscall.o.d ... -D__KBUILD_MODNAME=kmod_syscall -c
> -o kernel/bpf/syscall.o kernel/bpf/syscall.c ; ld.lld -EL -maarch64elf
> -z norelro -mllvm -import-instr-limit=5 -z noexecstack -r -o
> kernel/bpf/.tmp_syscall.o kernel/bpf/syscall.o; mv
> kernel/bpf/.tmp_syscall.o kernel/bpf/syscall.o I did some bisecting and
> found the issue is due to ``` commit
> bede169618c68379e1be7ace14e8ac85b964a9ec Author: Masahiro Yamada
> <masahiroy@...nel.org> Date: Thu Nov 14 08:45:22 2024 +0900 kbuild:
> enable objtool for *.mod.o and additional kernel objects ``` In the
> above, for thinlto, we should not do ld.lld as compiler needs IR to do
> cross-file inlining. Searching the internet, I found that the issue has
> been reported e.g. in
> https://patchwork.kernel.org/project/linux-kbuild/patch/20241113234526.402738-3-masahiroy@kernel.org/

It appears the fix suggested by Nathan is already squashed with the
commit before being merged upstream. However, this causes another
issue. As Yonghong stated, after upstream commit
bede169618c68379e1be7ace14e8ac85b964a9ec, the linker runs on
individual .o file, which defeats the benefit of LTO.

IIUC,  the proper behavior is to do "cmd_ld_single" only for "is-single-obj-m"
case. However, after bede169618c68379e1be7ace14e8ac85b964a9ec,
the "is-single-obj-m" check is removed. I am not quite sure what is the
proper fix for this.

Masahiro,

Could you please help us with this?

Thanks,
Song

> and you mentioned you will fix it. Do you have a fix somewhere? With
> this fix, deploying 6.13 in our production will cause performance
> regression and that is not what we want. Thanks! Yonghong