Documentation/livepatch/cumulative-patches.rst

Source file repositories/reference/linux-study-clean/Documentation/livepatch/cumulative-patches.rst

File Facts

System: Linux kernel
Corpus path: Documentation/livepatch/cumulative-patches.rst
Extension: .rst
Size: 3939 bytes
Lines: 103
Domain: Support Tooling And Documentation
Bucket: Documentation
Inferred role: Support Tooling And Documentation: exported/initcall integration point
Status: integration implementation candidate

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.
Exports symbols or registers init work; inspect boot/module ordering and who consumes the exported contract.
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

extra modifications in (un)patching callbacks or in the module_init()
    or module_exit() functions, see below.

    Also note that the replaced patch can be removed and loaded again
    only when the transition was not forced.


  - Only the (un)patching callbacks from the _new_ cumulative livepatch are
    executed. Any callbacks from the replaced patches are ignored.

    In other words, the cumulative patch is responsible for doing any actions
    that are necessary to properly replace any older patch.

    As a result, it might be dangerous to replace newer cumulative patches by
    older ones. The old livepatches might not provide the necessary callbacks.

    This might be seen as a limitation in some scenarios. But it makes life
    easier in many others. Only the new cumulative livepatch knows what
    fixes/features are added/removed and what special actions are necessary
    for a smooth transition.

    In any case, it would be a nightmare to think about the order of
    the various callbacks and their interactions if the callbacks from all
    enabled patches were called.


  - There is no special handling of shadow variables. Livepatch authors
    must create their own rules how to pass them from one cumulative
    patch to the other. Especially that they should not blindly remove
    them in module_exit() functions.

    A good practice might be to remove shadow variables in the post-unpatch
    callback. It is called only when the livepatch is properly disabled.

Annotation

Atlas domain: Support Tooling And Documentation / Documentation.
Implementation status: integration implementation candidate.

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.