From: Petr Mladek <pmladek@suse.com>
To: Miroslav Benes <mbenes@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
Joe Lawrence <joe.lawrence@redhat.com>,
Nicolai Stange <nstange@suse.de>,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [POC 7/7] livepatching: Remove per-state version
Date: Thu, 15 Aug 2024 16:00:25 +0200 [thread overview]
Message-ID: <Zr4J-U-HmmtxU-BB@pathway.suse.cz> (raw)
In-Reply-To: <alpine.LSU.2.21.2407251553420.21729@pobox.suse.cz>
On Thu 2024-07-25 16:16:44, Miroslav Benes wrote:
> On Fri, 10 Nov 2023, Petr Mladek wrote:
>
> > The livepatch state API was added to help with maintaining:
> >
> > + changes done by livepatch callbasks
> > + lifetime of shadow variables
> >
> > The original API was hard to use. Both objectives are better handled
> > by the new per-state callbacks. They are called when the state is
> > introduced or removed. There is also support for automatically freeing
> > obsolete shadow variables.
> >
> > The new callbacks changed the view of compatibility. The livepatch
> > can be replaced to any older one as long the current livepatch is
> > able to disable the obsolete state.
> >
> > As a result, the new patch does not need to support the currently
> > used states. The current patch will be able to disable them.
> >
> > The remaining question is what to do with the per-state version.
> > It was supposed to allow doing more modifications on an existing
> > state. The experience shows that it is not needed in practice.
> >
> > Well, it still might make sense to prevent downgrade when the state
> > could not be disabled easily or when the author does not want to
> > deal with it.
> >
> > Replace the per-state version with per-state block_disable flag.
> > It allows to handle several scenarios:
>
> I have no opinion to be honest. block_disable flag might be sufficient in
> the end.
>
> [...]
>
> > @@ -159,7 +159,9 @@ struct klp_state {
> > * @mod: reference to the live patch module
> > * @objs: object entries for kernel objects to be patched
> > * @states: system states that can get modified
> > + * version: livepatch version (optional)
> > * @replace: replace all actively used patches
> > + *
> > * @list: list node for global list of actively used patches
> > * @kobj: kobject for sysfs resources
> > * @obj_list: dynamic list of the object entries
> > @@ -173,6 +175,7 @@ struct klp_patch {
> > struct module *mod;
> > struct klp_object *objs;
> > struct klp_state *states;
> > + unsigned int version;
> > bool replace;
>
> Is it still needed then? What would be the use case?
Heh, I think that I actually wanted to remove the version completely.
This change is not mentioned in the changelog. And the version is
no longer used in the selftests.
I am going to remove it in the next version of the patchset.
> > /*
> > * Check that the new livepatch will not break the existing system states.
> > - * Cumulative patches must handle all already modified states.
> > - * Non-cumulative patches can touch already modified states.
> > + * The patch could replace existing patches only when the obsolete
> > + * states can be disabled.
> > */
> > bool klp_is_patch_compatible(struct klp_patch *patch)
> > {
> > struct klp_patch *old_patch;
> > struct klp_state *old_state;
> >
> > + /* Non-cumulative patches are always compatible. */
> > + if (!patch->replace)
> > + return true;
> > +
>
> Cumulative != atomic replace. Those are two different things.
I see. :-)
Best Regards,
Petr
next prev parent reply other threads:[~2024-08-15 14:00 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-10 17:04 [POC 0/7] livepatch: Make livepatch states, callbacks, and shadow variables work together Petr Mladek
2023-11-10 17:04 ` [POC 1/7] livepatch: Add callbacks for introducing and removing states Petr Mladek
2023-11-11 0:54 ` kernel test robot
2023-11-11 3:19 ` kernel test robot
2023-11-10 17:04 ` [POC 2/7] livepatch: Allow to handle lifetime of shadow variables using the livepatch state Petr Mladek
2024-07-25 11:31 ` Miroslav Benes
2024-08-15 13:43 ` Petr Mladek
2023-11-10 17:04 ` [POC 3/7] livepatch: Use per-state callbacks in state API tests Petr Mladek
2024-07-25 11:48 ` Miroslav Benes
2024-08-16 16:02 ` Petr Mladek
2023-11-10 17:04 ` [POC 4/7] livepatch: Do not use callbacks when testing sysfs interface Petr Mladek
2023-11-10 17:04 ` [POC 5/7] livepatch: Convert klp module callbacks tests into livepatch module tests Petr Mladek
2023-11-11 1:15 ` kernel test robot
2024-07-25 12:22 ` Miroslav Benes
2023-11-10 17:04 ` [POC 6/7] livepatch: Remove the obsolete per-object callbacks Petr Mladek
2023-11-10 17:04 ` [POC 7/7] livepatching: Remove per-state version Petr Mladek
2024-07-25 14:16 ` Miroslav Benes
2024-08-15 14:00 ` Petr Mladek [this message]
2023-11-10 21:33 ` [POC 0/7] livepatch: Make livepatch states, callbacks, and shadow variables work together Josh Poimboeuf
2024-07-25 14:19 ` Miroslav Benes
2024-08-15 10:08 ` Petr Mladek
2024-07-25 14:22 ` Miroslav Benes
2024-07-25 14:40 ` Nicolai Stange
[not found] ` <66a263d5.170a0220.b2c84.1870SMTPIN_ADDED_BROKEN@mx.google.com>
2024-08-21 15:28 ` 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=Zr4J-U-HmmtxU-BB@pathway.suse.cz \
--to=pmladek@suse.com \
--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=nstange@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).