All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harry Hsu <x90613@gmail.com>
To: pmladek@suse.com
Cc: jpoimboe@kernel.org, jikos@kernel.org, mbenes@suse.cz,
	joe.lawrence@redhat.com, live-patching@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] livepatch: Fix stack check for aliased old_func
Date: Sun, 23 Aug 2026 13:00:29 +0800	[thread overview]
Message-ID: <20260823050029.35979-1-x90613@gmail.com> (raw)
In-Reply-To: <aohuTo9QOhzvCkP2@pathway.suse.cz>

On Fri 2026-08-21 17:27:10, Petr Mladek wrote:
> This might fix klp_check_stack_func() for A. But not for B. B won't
> be the last entry so that klp_check_stack_func() would use
> the list_next_entry() and will check for A on stack instead of
> the original function.
>
> Another _big problem_ is in klp_ftrace_handler(). It would use A
> in PATCHED state and B in UNPATCHED. But it is not clear whether
> A or B should be used in the PATCHED state. And it should use
> the original code in UNPATCHED state.
>
> IMHO, we must catch this situation when preparing livepatches
> and when enabling the livepatch. A single livepatch must never
> create two entries on any ops->func_stack.
>
> IMHO, we should catch the duplicate (aliased) entries in
> klp_init_object_loaded() and return -EINVAL when they are found.
>
> I do not see any other solution. We could not decide which
> struct klp_func should be used for the redirection when
> more of them point to the same original function.

You're right, thanks for pointing this out. list_is_last() only
patches over the stack-check symptom for A and still leaves B wrong,
and it does nothing for the klp_ftrace_handler() ambiguity you
describe - there's really no sound way to pick between A and B once
they're both live entries backed by the same old_func.

Rejecting the duplicate at load time is the right fix. I'll send a
v2 that detects aliased old_func addresses within the same klp_object
in klp_init_object_loaded() and returns -EINVAL when found, instead
of touching klp_check_stack_func().

Thanks,
Harry

      reply	other threads:[~2026-08-23  5:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12 14:02 [PATCH] livepatch: Fix stack check for aliased old_func Harry Hsu
2026-08-12 15:07 ` sashiko-bot
2026-08-21 15:27 ` Petr Mladek
2026-08-23  5:00   ` Harry Hsu [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=20260823050029.35979-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 \
    /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.