The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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


  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