All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Song Liu <song@kernel.org>
Cc: Yafang Shao <laoar.shao@gmail.com>,
	jpoimboe@kernel.org, jikos@kernel.org, mbenes@suse.cz,
	joe.lawrence@redhat.com, live-patching@vger.kernel.org
Subject: Re: [RFC PATCH 1/6] livepatch: Support scoped atomic replace using replace set
Date: Tue, 26 May 2026 12:35:32 +0200	[thread overview]
Message-ID: <ahV3dBovdQZoF__j@pathway.suse.cz> (raw)
In-Reply-To: <CAPhsuW6Aa8Tu5aWGVYzRVVNEnJiHrNzsa4aKXoOEa_gwhp3XfQ@mail.gmail.com>

On Mon 2026-05-18 14:25:04, Song Liu wrote:
> On Wed, May 13, 2026 at 7:34 AM Yafang Shao <laoar.shao@gmail.com> wrote:
> >
> > Convert the replace attribute from a boolean to a u32 to function as a
> > "replace set." A newly loaded livepatch will now atomically replace
> > existing patches that belong to the same set.
> >
> > This change currently supports function replacement only; support for
> > state and shadow variables will be introduced in subsequent patches.
> >
> > Suggested-by: Song Liu <song@kernel.org>
> > Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
> > ---
> >  .../livepatch/cumulative-patches.rst          | 17 ++++++++------
> >  Documentation/livepatch/livepatch.rst         | 23 +++++++++++--------
> >  include/linux/livepatch.h                     |  5 ++--
> >  kernel/livepatch/core.c                       | 16 ++++++++-----
> >  kernel/livepatch/state.c                      | 17 +++++++-------
> >  kernel/livepatch/transition.c                 | 10 ++++----
> >  scripts/livepatch/init.c                      |  7 +-----
> >  scripts/livepatch/klp-build                   | 14 +++++------
> >  8 files changed, 59 insertions(+), 50 deletions(-)
> >
> > diff --git a/Documentation/livepatch/cumulative-patches.rst b/Documentation/livepatch/cumulative-patches.rst
> > index 1931f318976a..6ef49748110e 100644
> > --- a/Documentation/livepatch/cumulative-patches.rst
> > +++ b/Documentation/livepatch/cumulative-patches.rst
> > @@ -17,18 +17,20 @@ from all older livepatches and completely replace them in one transition.
> >  Usage
> >  -----
> >
> > -The atomic replace can be enabled by setting "replace" flag in struct klp_patch,
> > -for example::
> > +The "replace_set" attribute in ``struct klp_patch`` acts as a **replace set**,
> > +defining the scope of the replacement. By default, the replace set is 1.
> > +
> > +For example::
> >
> >         static struct klp_patch patch = {
> >                 .mod = THIS_MODULE,
> >                 .objs = objs,
> > -               .replace = true,
> > +               .replace_set = 1,
> >         };
> 
> I wonder whether we should have "replace_set = 0" means no replace.
> This will simplify the transition for users of the existing replace=false
> option. I would like to hear other folks' thoughts on this.

I would find this confusing. Also it would complicate the code.

I always considered the "replace" and "no replace" mode as two
separate worlds:

    + people using many "no replace" livepatches
    + people always using atomic replace

But the code had to handle also the world where:

    + people might combine "no replace" and "replace all" livepatches

which looked like a clash of the two worlds. And different people might
have different expectations about the behavior.

The "replace_set" allows to remove this clash. It looks like a win-win.
And it makes the change acceptable for me.

Best Regards,
Petr

  reply	other threads:[~2026-05-26 10:35 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-13 14:33 [RFC PATCH 0/6] livepatch: Introduce replace set support Yafang Shao
2026-05-13 14:33 ` [RFC PATCH 1/6] livepatch: Support scoped atomic replace using replace set Yafang Shao
2026-05-14 20:54   ` sashiko-bot
2026-05-17 13:32     ` Yafang Shao
2026-05-18 21:25   ` Song Liu
2026-05-26 10:35     ` Petr Mladek [this message]
2026-05-26 18:27       ` Song Liu
2026-05-27  2:17         ` Yafang Shao
2026-05-26 12:52   ` Petr Mladek
2026-05-27  2:37     ` Yafang Shao
2026-05-13 14:33 ` [RFC PATCH 2/6] livepatch: Add callbacks for introducing and removing states Yafang Shao
2026-05-13 14:33 ` [RFC PATCH 3/6] livepatch: Allow to handle lifetime of shadow variables using the livepatch state Yafang Shao
2026-05-14 22:07   ` sashiko-bot
2026-05-18  3:24     ` [PATCH] " Yafang Shao
2026-05-13 14:33 ` [RFC PATCH 4/6] livepatch: Remove "data" from struct klp_state Yafang Shao
2026-05-14 22:22   ` sashiko-bot
2026-05-13 14:33 ` [RFC PATCH 5/6] livepatch: Remove obsolete per-object callbacks Yafang Shao
2026-05-14 22:40   ` sashiko-bot
2026-05-19  6:46     ` Yafang Shao
2026-05-13 14:33 ` [RFC PATCH 6/6] livepatch: Support replace_set in shadow variable API Yafang Shao
2026-05-14 23:01   ` sashiko-bot
2026-05-19  6:56     ` Yafang Shao
2026-05-26 13:04   ` Petr Mladek
2026-05-26 13:13 ` [RFC PATCH 0/6] livepatch: Introduce replace set support 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=ahV3dBovdQZoF__j@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=jikos@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@kernel.org \
    --cc=laoar.shao@gmail.com \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --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.