From: Joe Lawrence <joe.lawrence@redhat.com>
To: George Guo <dongtai.guo@linux.dev>
Cc: chenhuacai@kernel.org, jpoimboe@kernel.org, peterz@infradead.org,
jikos@kernel.org, mbenes@suse.cz, pmladek@suse.com,
kernel@xen0n.name, rostedt@goodmis.org, ardb@kernel.org,
nathan@kernel.org, nick.desaulniers+lkml@gmail.com,
yangtiezhu@loongson.cn, jiaxun.yang@flygoat.com,
liukexin@kylinos.cn, guodongtai@kylinos.cn, xry111@xry111.site,
wangyuli@aosc.io, loongarch@lists.linux.dev,
live-patching@vger.kernel.org, llvm@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/8] LoongArch: Mark special sections for KLP support
Date: Wed, 1 Jul 2026 19:06:58 -0400 [thread overview]
Message-ID: <akWdkjS4zXYoj0-O@redhat.com> (raw)
In-Reply-To: <20260608100852.325413-3-dongtai.guo@linux.dev>
On Mon, Jun 08, 2026 at 06:08:46PM +0800, George Guo wrote:
> From: George Guo <guodongtai@kylinos.cn>
>
> objtool needs to split the kernel's special sections into per-entry
> symbols when generating livepatch modules. Mark them so it can:
>
> - .altinstructions and __ex_table are read-only, so set an explicit
> entry size via SHF_MERGE (ALT_INSTR_SIZE / EXTABLE_SIZE).
>
> - __bug_table and __jump_table are writable. SHF_MERGE cannot be
> combined with SHF_WRITE (Clang rejects it), so annotate each entry
> with ANNOTATE_DATA_SPECIAL instead, mirroring x86/arm64.
>
> Co-developed-by: Kexin Liu <liukexin@kylinos.cn>
> Signed-off-by: Kexin Liu <liukexin@kylinos.cn>
> Signed-off-by: George Guo <guodongtai@kylinos.cn>
> ---
Hi George,
Disclaimer: I don't have LoongArch hardware, so the best I can do with
this patchset is to read and poke at it with (cross) compilation.
For the special sections, said cross compiler (loongarch64-linux-gnu-gcc
(GCC) 15.2.1 20250808 (Red Hat Cross 15.2.1-1)) is interesting as it
appears to emit relocs in special sections (__ex_table,
.altinstructions, __bug_table, __jump_table) that point to local
assembler labels in the function's text section rather than the section
symbol + offset.
An example gcc / loongarch .rela__ex_table section looks like:
Relocation section '.rela__ex_table' at offset 0x6a28 contains 10 entries:
Offset Info Type Symbol's Value Symbol's Name + Addend
0000000000000000 0000005d00000063 R_LARCH_32_PCREL 00000000000011f0 .L1^B4 + 0
0000000000000004 0000005e00000063 R_LARCH_32_PCREL 00000000000011f4 .L2^B1 + 0
[ ... snip ... ]
Unlike everywhere else ...
llvm / loongarch:
Relocation section '.rela__ex_table' at offset 0x5710 contains 10 entries:
Offset Info Type Symbol's Value Symbol's Name + Addend
0000000000000000 0000000200000063 R_LARCH_32_PCREL 0000000000000000 .text + 2a70
0000000000000004 0000000200000063 R_LARCH_32_PCREL 0000000000000000 .text + 2a74
gcc / x86:
Relocation section '.rela__ex_table' at offset 0x40f50 contains 2 entries:
Offset Info Type Symbol's Value Symbol's Name + Addend
0000000000000000 0000000200000002 R_X86_64_PC32 0000000000000000 .text + 1596
0000000000000004 0000000200000002 R_X86_64_PC32 0000000000000000 .text + 159b
llvm / x86:
Relocation section '.rela__ex_table' at offset 0x343d8 contains 2 entries:
Offset Info Type Symbol's Value Symbol's Name + Addend
0000000000000000 0000000200000002 R_X86_64_PC32 0000000000000000 .text + 231a
0000000000000004 0000000200000002 R_X86_64_PC32 0000000000000000 .text + 231f
gcc / aarch64:
Relocation section '.rela__ex_table' at offset 0x448c8 contains 10 entries:
Offset Info Type Symbol's Value Symbol's Name + Addend
0000000000000000 0000000200000105 R_AARCH64_PREL32 0000000000000000 .text + 24bc
0000000000000004 0000000200000105 R_AARCH64_PREL32 0000000000000000 .text + 2524
[ ... snip ... ]
llvm / aarch64 Relocation section '.rela__ex_table' at offset 0x37760 contains 10 entries:
Offset Info Type Symbol's Value Symbol's Name + Addend
0000000000000000 0000000200000105 R_AARCH64_PREL32 0000000000000000 .text + 2730
0000000000000004 0000000200000105 R_AARCH64_PREL32 0000000000000000 .text + 264c
[ ... snip ... ]
The objtool/klp-diff.c implications is that
convert_reloc_secsym_to_sym() doesn't handle such non-section symbol
relocs in special sections:
if (!is_sec_sym(sym))
return 0;
That early return leaves the reloc pointing at a .L* symbol that is
never cloned into the output livepatch object. When
clone_special_section() later calls should_keep_special_sym() to decide
whether to include each table entry, it cannot map the reloc to an
included function and silently drops it. In the __ex_table case above,
the patched function's entries are missing from the .ko. As far as I
can tell, this problem applies to other special sections (like
.altinstructions, etc.) as well.
If not GCC / GAS is to be supported, then klp-diff will need to handle
this alternate relocation format. Perhaps these could be pre-converted
in convert_reloc_secsym_to_sym() to the general form (func_sym +
(label_offset - func_offset)) that is expected? I don't know if that's
enough to keep everything hanging together, but might be a place to
start.
--
Joe
next prev parent reply other threads:[~2026-07-01 23:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 10:08 [PATCH v2 0/8] LoongArch: Add livepatch build (KLP) support George Guo
2026-06-08 10:08 ` [PATCH v2 1/8] objtool/LoongArch: Add arch_adjusted_addend() for KLP support George Guo
2026-06-08 10:08 ` [PATCH v2 2/8] LoongArch: Mark special sections " George Guo
2026-07-01 23:06 ` Joe Lawrence [this message]
2026-06-08 10:08 ` [PATCH v2 3/8] livepatch/klp-build: disable direct-extern-access for LoongArch to fix kernel panic George Guo
2026-06-08 10:08 ` [PATCH v2 4/8] livepatch/klp-build: build LoongArch with -fPIC to keep GOT-indirect symbol references George Guo
2026-06-08 10:08 ` [PATCH v2 5/8] LoongArch: Fix EFI linking with -fdata-sections George Guo
2026-06-08 10:08 ` [PATCH v2 6/8] objtool/klp: Add LoongArch jump opcode bytes support George Guo
2026-06-08 10:08 ` [PATCH v2 7/8] klp-build: Add LoongArch syscall patching macro George Guo
2026-06-08 10:08 ` [PATCH v2 8/8] LoongArch: Add livepatch build (KLP) support George Guo
2026-07-02 20:00 ` [PATCH v2 0/8] " Joe Lawrence
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=akWdkjS4zXYoj0-O@redhat.com \
--to=joe.lawrence@redhat.com \
--cc=ardb@kernel.org \
--cc=chenhuacai@kernel.org \
--cc=dongtai.guo@linux.dev \
--cc=guodongtai@kylinos.cn \
--cc=jiaxun.yang@flygoat.com \
--cc=jikos@kernel.org \
--cc=jpoimboe@kernel.org \
--cc=kernel@xen0n.name \
--cc=linux-kernel@vger.kernel.org \
--cc=liukexin@kylinos.cn \
--cc=live-patching@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=loongarch@lists.linux.dev \
--cc=mbenes@suse.cz \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=wangyuli@aosc.io \
--cc=xry111@xry111.site \
--cc=yangtiezhu@loongson.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox