1. Livepatch system state API¶

The state of the system might get modified either by several livepatch callbacksor by the newly used code. Also it must be possible to find changes done byalready installed livepatches.

Each modified state is described by struct klp_state, seeinclude/linux/livepatch.h.

Each livepatch defines an array of struct klp_states. They mentionall states that the livepatch modifies.

The livepatch author must define the following two fields for eachstruct klp_state:

• id
  • Non-zero number used to identify the affected system state.
• version
  • Number describing the variant of the system state change thatis supported by the given livepatch.

The state can be manipulated using two functions:

• klp_get_state(patch, id)
  • Get struct klp_state associated with the given livepatchand state id.
• klp_get_prev_state(id)
  • Get struct klp_state associated with the given feature id andalready installed livepatches.

2. Livepatch compatibility¶

The system state version is used to prevent loading incompatible livepatches.The check is done when the livepatch is enabled. The rules are:

• Any completely new system state modification is allowed.
• System state modifications with the same or higher version are allowedfor already modified system states.
• Cumulative livepatches must handle all system state modifications fromalready installed livepatches.
• Non-cumulative livepatches are allowed to touch already modifiedsystem states.

3. Supported scenarios¶

Livepatches have their life-cycle and the same is true for the systemstate changes. Every compatible livepatch has to support the followingscenarios:

• Modify the system state when the livepatch gets enabled and the statehas not been already modified by a livepatches that are beingreplaced.
• Take over or update the system state modification when is has alreadybeen done by a livepatch that is being replaced.
• Restore the original state when the livepatch is disabled.
• Restore the previous state when the transition is reverted.It might be the original system state or the state modificationdone by livepatches that were being replaced.
• Remove any already made changes when error occurs and the livepatchcannot get enabled.

4. Expected usage¶

System states are usually modified by livepatch callbacks. The expectedrole of each callback is as follows:

pre_patch()

• Allocatestate->data when necessary. The allocation might failandpre_patch() is the only callback that could stop loadingof the livepatch. The allocation is not needed when the dataare already provided by previously installed livepatches.

• Do any other preparatory action that is needed bythe new code even before the transition gets finished.For example, initializestate->data.

  The system state itself is typically modified inpost_patch()when the entire system is able to handle it.

• Clean up its own mess in case of error. It might be done by a customcode or by callingpost_unpatch() explicitly.

post_patch()

• Copystate->data from the previous livepatch when they arecompatible.
• Do the actual system state modification. Eventually allowthe new code to use it.
• Make sure thatstate->data has all necessary information.
• Freestate->data from replaces livepatches when they arenot longer needed.

pre_unpatch()

• Prevent the code, added by the livepatch, relying on the systemstate change.
• Revert the system state modification..

post_unpatch()

• Distinguish transition reverse and livepatch disabling bycheckingklp_get_prev_state().
• In case of transition reverse, restore the previous systemstate. It might mean doing nothing.
• Remove any not longer needed setting or data.