On Wed, Jun 10, 2026 at 12:00 AM Petr Mladek <[email protected]> wrote: > > On Sun 2026-06-07 21:16:55, Yafang Shao wrote: > > Convert the replace attribute from a boolean to a u32 to function as a > > "replace set." A newly loaded livepatch will now atomically replace any > > existing patch belonging to the same set. There can only ever be one active > > livepatch for a given replace_set number. > > > > This change currently supports function replacement only. Livepatches that > > belong to different replace sets cannot modify the same function. If a new > > livepatch attempts to modify a function already modified by an older > > livepatch from a different replace_set, the loading of the new livepatch > > will be refused. > > > > Similarly, for the KLP state, livepatches belonging to different replace > > sets cannot use the same state ID. The system will refuse to load a new > > livepatch if it uses a state ID already in use by an older livepatch from > > a different replace_set. > > > > For the KLP shadow variable mechanism, developers must assign unique shadow > > IDs to livepatches that belong to different replace sets. > > > > Support for replace_set compatibility with KLP state and shadow variables > > will be implemented after Petr's KLP state transfer work is completed [0]. > > > > Other user-visible changes include: > > - The non-replace model is now deprecated > > - /sys/kernel/livepatch/livepatch_XXX/replace attribute is replaced by > > /sys/kernel/livepatch/livepatch_XXX/replace_set > > The commit message is not bad. But the patch is breaking the backward > compatibility. We should explain the motivation first. > > I would write something like: > > <proposal> > The practice shows that the current semantic of the patch.replace flag is > not ideal. > > The atomic replace is disabled by default. And the no-replace mode allows > wild installation of many livepatches in parallel. The author and > administrator are fully responsible for preventing problems caused > by producing and installing incompatible livepatches. > > The most safe atomic replace mode must be explicitly enabled by > setting "patch.replace = true". It is all or nothing. The livepatch > with enabled .replace will always replace all already installed > livepatches. It makes it very safe but it might be too harsh. > > Improve the situation by switching "bool .replace" flag to > "u32 .replace_set" and and updating its semantic. > > Any .replace_set value might be associated with a set of livepatched > symbols, callbacks, shadow variable and state IDs. > > A livepatch with a particular .replace_set number will atomically > rreplace any already installed livepatch with the same .replace_set > number. By definition, there can only ever be one active livepatch > for a given replace_set number. > > On the contrary, livepatches with a different .replace_set number > must not modify the same function, or use the state with the same > ID [*]. Any attempt to load an incompatible livepatch will be > rejected. > > Summary: > > The most safe mode when any livepatch replaces any other livepatch > will be the default. Note that all livepatches must keep > .replace_set = 0. > > It will be possible to install more livepatches in parallel by > using different .replace_set numbers. The livepatches might be > updated independently using the atomic replace feature as long > as the new version does not break compatibility. The kernel will > reject a livepatch from a different replace set when it would > want to modify the same function or livepatch state from > another replace set. > > [*] The compatibility check of callbacks and shadow variables will > be improved later by reworking their semantic. There is a work > in progress, see [0] > </proposal> > > > Link: https://github.com/pmladek/linux/tree/klp-state-transfer-v1-iter12 [0] > > I have realized that I actually sent "v1-iter12" to the public > mailing list as the official v1. So we could use: > > Link: https://lore.kernel.org/all/[email protected]/ [0]
Thanks for refining the commit message. I will update it. > > > New idea: > > I have briefly discussed the new semantic with Miroslav when I met > him in person. And he was a bit concerned. We as an OS distributor > might want to be sure that our livepatches can be installed the most > safe way. So, we still might want to preserve the "replace all" > semantic to make sure that our livepatches will not break anything. > > I though about 4 approaches approaches: > > 1. Make .replace_set=0 special so that it will always replace > everything. Similar to the current .replace=true mode. > > Customers will still be able to install custom livepatches > later with .replace_set != 0. But the "0" livepatch will > always wipe them out. > > > 2. Use two flags in the livepatch, for example > > a. Rename .replace to .replace_all. The livepatch with this > flag set will always wipe all other livepatches. > > b. Add .replace_set which will allow to install more livepatches > in parallel, replace the livepatches with the same .replace_set > atomically, and check the compatibility. As described above. > > It is a bit more complicated. But it is more compatible with > the current state. And it removes the special meaning of > .replace_set == 0. > > > 3. Introduce a system wide flag, sysctl livepatch_replace_all > which would allow to enable/disable the replace_all feature > of either .replace_set == 0 or per-patch.replace_all flag. > > It would allow the customer to preserve their custom livepatches > when they know what they do. For example, when they use the livepatch > to modify a 3rd party module or tune some functionality. > > > 4. Just taint the kernel when a livepatch with .replace_set != 0 > is installed. Then the OS provider could say that a tainted kernel > is not longer officially supported. Since the kernel is already tainted with TAINT_LIVEPATCH upon loading a livepatch, are you recommending the addition of a distinct flag, such as TAINT_LIVEPATCH_REPLACE_SET? > > > I personally prefer the 4th solution because it is simple. > > > Best Regards, > Petr > > PS: I still have to review the actual code changes. I'll do > it in a separate mail, ... -- Regards Yafang
