Re: [PATCH v13 0/9] livepatch: Add support for scoped atomic replace

[Petr Mladek]

On Mon 2026-10-26 21:36:42, Yafang Shao wrote:
> Atomic replacement is currently all-or-nothing: a livepatch with
> "replace" set either atomically replaces all previously installed
> livepatches, or - with "replace" disabled - it replaces none. There
> is no way to atomically replace only a selected set of livepatches
> while keeping the rest running untouched.
> 
> We previously proposed a BPF+livepatch method to enable rapid
> experimentation with new kernel features without interrupting production
> workloads:
> 
>   https://lore.kernel.org/live-patching/20260402092607.96430-1-laoar.shao@xxxxxxxxx/
> 
> In the resulting discussion, Song and Petr suggested that it should be
> possible to selectively replace or skip individual livepatches.
> 
> This patchset introduces a more flexible model using two new fields in
> struct klp_patch:
> 
> - provides: an unsigned int id identifying the replacement scope of
>   the livepatch. Livepatches that share the same provides id replace
>   each other, so at most one livepatch of each provides id can be
>   enabled at a time. By default (provides=0), every livepatch that
>   does not declare an explicit provides id belongs to the same scope:
>   loading a new provides=0 livepatch atomically replaces the
>   previously enabled one.
> 
> - obsoletes: an optional array of unsigned int ids specifying
>   additional provides ids to be replaced. This allows a new patch
>   to explicitly obsolete patches from different scopes.
> 
> A new livepatch atomically replaces any existing livepatch that
> satisfies either of the following conditions:
> 
>   1. it has the same provides id as the new patch,
>   2. its provides id is listed in the new patch's obsoletes list.
> 
> A new livepatch that does not replace an existing one can coexist
> with it. In this case, the two livepatches must not modify the same
> function, or use the state with the same id. Any attempt to load an
> incompatible livepatch will be rejected by the kernel.
> 
> Previously, setting 'replace' to 0 was the only way to keep
> certain livepatches persistent on the system, forcing developers to
> disable atomic replacement entirely. With the introduction of provides
> and obsoletes, developers now have a selective option to keep specific
> livepatches persistent while maintaining atomic replacement capabilities
> elsewhere.
> 
> IMPORTANT:
> - this design deprecates the traditional non-atomic-replace model.
> - the behavior of replacing all non-atomic-replace livepatches with a
>   single atomic-replace livepatch is also deprecated.
> 
> The new "provides" and "obsoletes" attributes are exposed through
> sysfs and the kselftests cover the replacement and coexistence
> semantics described above.
> 
> At present, KLP state, shadow variables, and callbacks are not
> integrated with the new provides/obsoletes mechanism in this patchset.
> Support for these features is deferred until Petr's klp-state-transfer
> infrastructure is completed and merged:
> 
>   https://github.com/pmladek/linux/tree/klp-state-transfer-v1-iter12
> 
> It is based on livepatching tree's for-next branch.

I double checked the patchset and it looks ready for linux-next.

Just to be sure, Joe, Josh, anyone else, would you still like
to review this patchset, please? I am going to commit it early
next week unless anyone complains ;-)

Best Regards,
Petr