All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harry Hsu <x90613@gmail.com>
To: pmladek@suse.com, jpoimboe@kernel.org, mbenes@suse.cz,
	joe.lawrence@redhat.com
Cc: jikos@kernel.org, live-patching@vger.kernel.org,
	shuah@kernel.org, song@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 0/5] livepatch: Fail object initialization on duplicate patched function
Date: Thu, 29 Oct 2026 00:46:49 +0800	[thread overview]
Message-ID: <20261028164649.337479-1-x90613@gmail.com> (raw)
In-Reply-To: <att7GJXA7hK7Ic64@pathway.suse.cz>

On Fri 2026-10-23, Petr Mladek wrote:
> I wonder how to move forward with this patchset. There seems to be
> three unresolved problems:
>
>   1. How to handle aliased functions when replacing two livepatches
>      with aliased symbols, aka two NOPs on the same stack [1].
>
>      My take: I would fix this later on top of scoped atomic replace.
>               The aliased symbols should conflict.
>   2. Fix the low-level __write_relocate_add() to clean its own
>      mess on failure.
>
>      My take: I would fix this a follow up patch.
>
>   3. Better describe the purpose of klp_write_object_relocs_limited().
>      Or clean its own mess a better way (code duplication)?
>
>      My take:  This requires v5.

For 1, I have a proposal to create only one NOP in the first place,
as in your solution 1 from the earlier mail.


Recap: The problem
-----------

Take two livepatches that are already loaded:
  A patches __do_sys_fork
  B patches __x64_sys_fork        (same address as __do_sys_fork)

and an atomic replace livepatch C that patches neither of them.
klp_add_nops() finds the functions by name and sympos only, so C
inherits two NOPs. Both resolve to the same address and end up on
the same ops->func_stack: [A, B, nop1, nop2]. When the transition
is reverted, the stack goes from nop2 to nop1 instead of back to B.


Proposal
--------

klp_add_nops() runs from klp_init_patch() before klp_init_object(),
so the new NOPs have no address yet. But func->old_func of the old
livepatches is already resolved when their object is loaded. So the
address can be used as a hint when the NOPs are created:

  1. Copy the already resolved address of the old function into the
     new NOP (func->old_func) as an address hint.
  2. Do not create another NOP when a NOP with the same address
     already exists in the object.

The hint is overwritten by klp_find_object_symbol() in
klp_init_object_loaded() with the same value. It is cleared again by
klp_free_object_loaded(), so it never outlives the loaded object.

A sketch of the change in kernel/livepatch/core.c:

+/*
+ * Return true when @obj already has a nop whose address hint is @addr.
+ * The hint is only set when the livepatched object was already loaded.
+ */
+static bool klp_nop_exists_at(struct klp_object *obj, void *addr)
+{
+	struct klp_func *func;
+
+	if (!addr)
+		return false;
+
+	klp_for_each_func(obj, func) {
+		if (func->nop && func->old_func == addr)
+			return true;
+	}
+
+	return false;
+}
+
 static int klp_add_object_nops(struct klp_patch *patch,
 			       struct klp_object *old_obj)
 {
@@
 	klp_for_each_func(old_obj, old_func) {
 		func = klp_find_func(obj, old_func);
 		if (func)
 			continue;

+		/*
+		 * Aliased symbols resolve to the same address. A single nop
+		 * is enough. More nops on the same ops->func_stack would
+		 * break reverting the transition.
+		 */
+		if (klp_nop_exists_at(obj, old_func->old_func))
+			continue;
+
 		func = klp_alloc_func_nop(old_func, obj);
 		if (!func)
 			return -ENOMEM;
+
+		/* Address hint for klp_nop_exists_at(). */
+		func->old_func = old_func->old_func;
 	}

That's only one way I can come up with :D

Best Regards,
Harry

  reply	other threads:[~2026-10-28 16:46 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-08 12:03 [PATCH v4 0/5] livepatch: Fail object initialization on duplicate patched function Petr Mladek
2026-09-08 12:03 ` [PATCH v4 1/5] " Petr Mladek
2026-09-08 12:17   ` sashiko-bot
2026-09-08 13:02     ` Petr Mladek
2026-09-18 12:54       ` Miroslav Benes
2026-09-30 14:11         ` [PATCH v4 1/3] " Harry Hsu
2026-10-01  4:32         ` [PATCH v4 1/5] " Harry Hsu
2026-10-23 14:17           ` Petr Mladek
2026-10-27 14:02             ` Miroslav Benes
2026-09-08 12:03 ` [PATCH v4 2/5] selftests/livepatch: Test rejection of aliased symbols in one object Petr Mladek
2026-09-18 13:40   ` Miroslav Benes
2026-09-08 12:03 ` [PATCH v4 3/5] livepatch: Move code for updating livepatch object relocations Petr Mladek
2026-09-18 13:40   ` Miroslav Benes
2026-09-08 12:03 ` [PATCH v4 4/5] livepatch: Clear relocations when klp_apply_object_relocs() fails Petr Mladek
2026-09-08 12:18   ` sashiko-bot
2026-09-08 13:29     ` Petr Mladek
2026-09-18 13:59   ` Miroslav Benes
2026-09-18 14:05     ` Miroslav Benes
2026-10-23 15:05     ` Petr Mladek
2026-10-27 14:21       ` Miroslav Benes
2026-09-08 12:03 ` [PATCH v4 5/5] livepatch: Clean up klp_init_object_loaded() when fails Petr Mladek
2026-09-08 12:25   ` sashiko-bot
2026-09-08 13:32     ` Petr Mladek
2026-09-18 14:07   ` Miroslav Benes
2026-10-23 15:19 ` [PATCH v4 0/5] livepatch: Fail object initialization on duplicate patched function Petr Mladek
2026-10-28 16:46   ` Harry Hsu [this message]
2026-10-30  9:15     ` Petr Mladek

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=20261028164649.337479-1-x90613@gmail.com \
    --to=x90613@gmail.com \
    --cc=jikos@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=pmladek@suse.com \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    /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.