linux-kernel - Re: [PATCH v1] objtool/LoongArch: Mark special atomic instruction as INSN

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] [day] [month] [year] [list]

Message-ID: <b218d981-49a4-3ee3-6eb9-68953ec29b1e@loongson.cn>
Date: Tue, 16 Sep 2025 20:18:48 +0800
From: Tiezhu Yang <yangtiezhu@...ngson.cn>
To: WANG Rui <wangrui@...ngson.cn>
Cc: Huacai Chen <chenhuacai@...nel.org>, Miguel Ojeda <ojeda@...nel.org>,
 Josh Poimboeuf <jpoimboe@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
 rust-for-linux@...r.kernel.org, loongarch@...ts.linux.dev,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] objtool/LoongArch: Mark special atomic instruction as
 INSN_BUG type

On 2025/9/16 下午5:02, WANG Rui wrote:
> On Tue, Sep 16, 2025 at 2:11 PM Tiezhu Yang <yangtiezhu@...ngson.cn> wrote:
>>
>> When compiling with LLVM and CONFIG_RUST is set, there exists the
>> following objtool warning:
>>
>>    rust/compiler_builtins.o: warning: objtool: __rust__unordsf2(): unexpected end of section .text.unlikely.
>>
>> objdump shows that the end of section .text.unlikely is a atomic
>> instruction:
>>
>>    amswap.w        $zero, $ra, $zero
>>
>> According to the LoongArch Reference Manual, if the amswap.w atomic
>> memory access instruction has the same register number as rd and rj,
>> the execution will trigger an Instruction Non-defined Exception, so
>> mark the above instruction as INSN_BUG type to fix the warning.
> 
> LLVM lowers `llvm.trap()` to `amswap.w R0, R1, R0`. For x86, it lowers
> to `ud2`, and objtool marks it as INSN_BUG.
> 
> https://github.com/llvm/llvm-project/blob/788a25a0f71bfa5e5e1c12ad093993b115d10e7a/llvm/lib/Target/LoongArch/LoongArchInstrInfo.td#L1376-L1381

Thanks for the detailed explanation from the point of view of the
compiler.

> LLVM and GCC handle this differently, GCC lowers it to a break
> instruction. Since the break instruction has other uses, can objtool
> mark all break instructions as INSN_BUG? or it should mark different
> types based on the break immediate code.

If the break immediate code is 0, it should mark the type
as INSN_TRAP. If the break immediate code is 1, it should
mark the type as INSN_BUG. I will do it.

Thanks,
Tiezhu