Documentation/livepatch/system-state.rst
Source file repositories/reference/linux-study-clean/Documentation/livepatch/system-state.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/livepatch/system-state.rst- Extension
.rst- Size
- 5520 bytes
- Lines
- 168
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
====================
System State Changes
====================
Some users are really reluctant to reboot a system. This brings the need
to provide more livepatches and maintain some compatibility between them.
Maintaining more livepatches is much easier with cumulative livepatches.
Each new livepatch completely replaces any older one. It can keep,
add, and even remove fixes. And it is typically safe to replace any version
of the livepatch with any other one thanks to the atomic replace feature.
The problems might come with shadow variables and callbacks. They might
change the system behavior or state so that it is no longer safe to
go back and use an older livepatch or the original kernel code. Also
any new livepatch must be able to detect what changes have already been
done by the already installed livepatches.
This is where the livepatch system state tracking gets useful. It
allows to:
- store data needed to manipulate and restore the system state
- define compatibility between livepatches using a change id
and version
1. Livepatch system state API
=============================
The state of the system might get modified either by several livepatch callbacks
or by the newly used code. Also it must be possible to find changes done by
already installed livepatches.
Each modified state is described by struct klp_state, see
include/linux/livepatch.h.
Each livepatch defines an array of struct klp_states. They mention
all states that the livepatch modifies.
The livepatch author must define the following two fields for each
struct klp_state:
- *id*
- Non-zero number used to identify the affected system state.
- *version*
- Number describing the variant of the system state change that
is supported by the given livepatch.
The state can be manipulated using two functions:
- klp_get_state()
- Get struct klp_state associated with the given livepatch
and state id.
- klp_get_prev_state()
- Get struct klp_state associated with the given feature id and
already 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:
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.