linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Josh Poimboeuf <jpoimboe@kernel.org>, Miroslav Benes <mbenes@suse.cz>
Cc: Joe Lawrence <joe.lawrence@redhat.com>,
	Nicolai Stange <nstange@suse.de>,
	live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
	Petr Mladek <pmladek@suse.com>
Subject: [POC 0/7] livepatch: Make livepatch states, callbacks, and shadow variables work together
Date: Fri, 10 Nov 2023 18:04:21 +0100	[thread overview]
Message-ID: <20231110170428.6664-1-pmladek@suse.com> (raw)

This POC is a material for the discussion "Simplify Livepatch Callbacks,
Shadow Variables, and States handling" at LPC 2013, see
https://lpc.events/event/17/contributions/1541/

It obsoletes the patchset adding the garbage collection of shadow
variables. This new solution is based on ideas from Nicolai Stange.
And it should also be in sync with Josh's ideas mentioned into
the thread about the garbage collection, see
https://lore.kernel.org/r/20230204235910.4j4ame5ntqogqi7m@treble

What is this all about?

There are three features provided by the kernel livepatching support:

  + callbacks:

       They allow doing system modifications where the "simple"
       redirection to the fixed code is not enough. For example,
       allocate some data and allow to use them when all processes
       are patched.

       There are four optional callbacks which might be called
       either when the livepatch or the livepatched object is loaded.
       It depends who is loaded first.

       The are called at different stages of the livepatch transition:
       pre_enable, post_enable, pre_disable, post_disable.

       Only callbacks from the new livepatch are called during atomic
       replace. The motivation was that new livepatches should know
       how to handle the existing changes correctly. Also it
       simplified the semantic because it would be horrible when
       both callbacks from the old and new livepatch are called.
       The later one might break changes done by the earlier one.

       They are defined per-object. The idea was that they might
       be needed when a livepatched module is loaded or unloaded.


   + shadow variables:

      They allow attaching extra data to any existing data.
      For example, they allow to extend a structure. Or they
      allow to create a spin lock which might stay even
      when the livepatch gets atomically replaced.

      They are defined per-patch but there is no real connection.
      There is just an allocate/get/free API.


   + states:

      They were introduced to manage the life-cycle of changes
      done by the callbacks and shadow variables.

      They should help especially when atomic replace is used.
      The new livepatch need to know what changes have already
      been done or which need to be reverted.

      The states are defined per-patch. There was proposal
      to make them per-object but it was decided that it
      was not worth the complexity.

      Each state might have a version which allows to maintain
      compatibility between the livepatches. Otherwise, there
      is no connection with the other features. The is just an API
      to check whether the state was in the previous patch so that
      the callbacks might do an informed decisions.


Observation:

   + States were supposed to help with the life-time of changes
     done by callbacks. But states are per-patch and callbacks
     are per-object. Also the API is hard to use.

   + Shadow variables were not connected with the states at all.
     It needs to be done by callbacks.

   + The decision that only the callbacks from the new livepatch
     gets called during atomic replace make downgrades complicated.


Better solution implemented by this POC:

   + Transform per-object callbacks to per-state callbacks
     so that the state might really control the life-cycle
     of the changes.

   + Change the semantic of the callbacks, so that they
     are called when the state is introduced or removed.

     No callbacks are called when the state is just transferred
     during the atomic replace.


   + The disable/remove callbacks from the old livepatch are
     called from the old livepatch when the new one does
     not support them.

     These callbacks have to be there anyway so that the livepatch
     can get disabled.

     This nicely solves the problem with downgrades while keeping
     simple semantic.


   + A state might be associated with a shadow variable with
     the same ID.

     It helps to maintain the life-cycle of the shadow variable.

     The variable is automatically freed when the state is not longer
     supported during atomic replace or when the livepatch gets disabled.

     Also the state callbacks might help to allocate the variable
     do do some checks before the transition starts. But it can
     be enabled only after all processes are transitioned.

     It would prevent loading the livepatch when the shadow variable
     could not be used and the livepatch could cause problems.


   + State version is replaced with "block_disable" flag.

     The versions are too generic and make things complicated.

     In practice, the main question is whether the changes introduced
     by the state (callbacks) can be reverted or not. The livepatch
     could not be disabled or downgraded when the revert (state disable)
     is not supported.


What is done in this POC:

   + All changes in livepatch code are implemented.
   + The existing selftests are migrated [*]


What is missing:

   + The documentation is not updated.
   + More selftest might be needed [**]


[*] There is some mystery in a selftest when the migration gets
    blocked, see the comments in the 5th patch.

[**] In fact, many selftests would deserve some cleanup and 
     better split into categories.


Petr Mladek (7):
  livepatch: Add callbacks for introducing and removing states
  livepatch: Allow to handle lifetime of shadow variables using the
    livepatch state
  livepatch: Use per-state callbacks in state API tests
  livepatch: Do not use callbacks when testing sysfs interface
  livepatch: Convert klp module callbacks tests into livepatch module
    tests
  livepatch: Remove the obsolete per-object callbacks
  livepatching: Remove per-state version

 Documentation/livepatch/callbacks.rst         | 133 -----
 Documentation/livepatch/index.rst             |   1 -
 include/linux/livepatch.h                     |  75 ++-
 kernel/livepatch/core.c                       |  61 +-
 kernel/livepatch/core.h                       |  33 --
 kernel/livepatch/state.c                      | 151 ++++-
 kernel/livepatch/state.h                      |  10 +
 kernel/livepatch/transition.c                 |  13 +-
 lib/livepatch/Makefile                        |   8 +-
 lib/livepatch/test_klp_callbacks_busy.c       |  70 ---
 lib/livepatch/test_klp_callbacks_demo.c       | 121 ----
 lib/livepatch/test_klp_callbacks_demo2.c      |  93 ---
 lib/livepatch/test_klp_callbacks_mod.c        |  24 -
 lib/livepatch/test_klp_speaker.c              | 185 ++++++
 lib/livepatch/test_klp_speaker_livepatch.c    | 253 ++++++++
 lib/livepatch/test_klp_state.c                | 178 ++++--
 lib/livepatch/test_klp_state2.c               | 190 +-----
 lib/livepatch/test_klp_state3.c               |   2 +-
 samples/livepatch/Makefile                    |   3 -
 .../livepatch/livepatch-callbacks-busymod.c   |  60 --
 samples/livepatch/livepatch-callbacks-demo.c  | 196 -------
 samples/livepatch/livepatch-callbacks-mod.c   |  41 --
 tools/testing/selftests/livepatch/Makefile    |   2 +-
 .../testing/selftests/livepatch/functions.sh  |  46 ++
 .../selftests/livepatch/test-callbacks.sh     | 553 ------------------
 .../selftests/livepatch/test-modules.sh       | 539 +++++++++++++++++
 .../testing/selftests/livepatch/test-state.sh |  80 ++-
 .../testing/selftests/livepatch/test-sysfs.sh |  48 +-
 28 files changed, 1436 insertions(+), 1733 deletions(-)
 delete mode 100644 Documentation/livepatch/callbacks.rst
 delete mode 100644 lib/livepatch/test_klp_callbacks_busy.c
 delete mode 100644 lib/livepatch/test_klp_callbacks_demo.c
 delete mode 100644 lib/livepatch/test_klp_callbacks_demo2.c
 delete mode 100644 lib/livepatch/test_klp_callbacks_mod.c
 create mode 100644 lib/livepatch/test_klp_speaker.c
 create mode 100644 lib/livepatch/test_klp_speaker_livepatch.c
 delete mode 100644 samples/livepatch/livepatch-callbacks-busymod.c
 delete mode 100644 samples/livepatch/livepatch-callbacks-demo.c
 delete mode 100644 samples/livepatch/livepatch-callbacks-mod.c
 delete mode 100755 tools/testing/selftests/livepatch/test-callbacks.sh
 create mode 100755 tools/testing/selftests/livepatch/test-modules.sh

-- 
2.35.3


             reply	other threads:[~2023-11-10 17:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-10 17:04 Petr Mladek [this message]
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
2023-11-10 17:04 ` [POC 3/7] livepatch: Use per-state callbacks in state API tests 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
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
2023-11-10 21:33 ` [POC 0/7] livepatch: Make livepatch states, callbacks, and shadow variables work together Josh Poimboeuf

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=20231110170428.6664-1-pmladek@suse.com \
    --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).