All of lore.kernel.org
 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: 12+ 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
2026-07-06  9:53   ` George Guo

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.