All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Guo <dongtai.guo@linux.dev>
To: joe.lawrence@redhat.com
Cc: ardb@kernel.org, chenhuacai@kernel.org, guodongtai@kylinos.cn,
	jiaxun.yang@flygoat.com, jikos@kernel.org, jpoimboe@kernel.org,
	kernel@xen0n.name, linux-kernel@vger.kernel.org,
	liukexin@kylinos.cn, live-patching@vger.kernel.org,
	llvm@lists.linux.dev, loongarch@lists.linux.dev, mbenes@suse.cz,
	nathan@kernel.org, nick.desaulniers+lkml@gmail.com,
	peterz@infradead.org, pmladek@suse.com, rostedt@goodmis.org,
	wangyuli@aosc.io, xry111@xry111.site, yangtiezhu@loongson.cn
Subject: Re: [PATCH v2 0/8] LoongArch: Add livepatch build (KLP) support
Date: Mon,  6 Jul 2026 17:53:44 +0800	[thread overview]
Message-ID: <20260706095344.321644-1-dongtai.guo@linux.dev> (raw)
In-Reply-To: <akbDROiVKjbkqMZL@redhat.com>

Hi Joe,
Thanks for reviewing!

> Ok, what am I doing wrong here:
[...]
> What compiler / kernel config should I be trying with this patchset?

Nothing wrong on your side -- both things you hit are real bugs, thanks
for running the full flow.  Fixes for both (and for the special-section
reloc issue you reported earlier) are queued for v3.  Quick answers to
the compiler/config question:

Compiler:

 - GCC: this is what the series was tested with, on real LoongArch
   hardware (livepatch modules generated, loaded and exercised).
 - LLVM: your clang 21 is fine.  Note that klp-build itself requires
   the LLVM assembler >= 20.

Config:

 - defconfig plus your script is exactly right.
 - The FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY select you added is
   the proper fix, not a workaround: arch/loongarch/Makefile already
   builds with -fpatchable-function-entry=2.  v3 adds exactly that as
   a patch, with your Reported-by/Suggested-by if that's ok with you.

On the "duplicate reloc" error: reproduced and fixed.  The key field
of a __jump_table entry is a cross-section difference (".quad key - ."),
and clang's integrated assembler emits it as a relocation pair at the
same offset when the key is not defined in the same translation unit:

  $ readelf -rW net/core/dev.o        # clang 21.1.8
  0x18  R_LARCH_ADD64  __tracepoint_netif_rx + 8
  0x18  R_LARCH_SUB64  __jump_table + 0x18

Locally-defined keys (e.g. netstamp_needed_key) get a single
R_LARCH_64_PCREL instead, and GAS emits the single form in both cases,
which is why a GCC build never trips on this.  objtool's
elf_create_reloc() allows only one relocation per offset, so cloning
such an entry fails on the SUB half.

The fix queued for v3 folds the pair into the single equivalent
R_LARCH_64_PCREL (which the module loader already supports).  With it,
your exact test.patch now builds cleanly here with clang 21.1.8 on
LoongArch hardware; the tracepoint key correctly ends up as a klp
relocation against .klp.sym.vmlinux.__tracepoint_netif_rx.

Thanks,
George

      reply	other threads:[~2026-07-06  9:54 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
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 [this message]

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=20260706095344.321644-1-dongtai.guo@linux.dev \
    --to=dongtai.guo@linux.dev \
    --cc=ardb@kernel.org \
    --cc=chenhuacai@kernel.org \
    --cc=guodongtai@kylinos.cn \
    --cc=jiaxun.yang@flygoat.com \
    --cc=jikos@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --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.