On Thu, Apr 9, 2026 at 3:36 PM Petr Mladek <[email protected]> wrote: > > On Wed 2026-04-08 11:19:50, Song Liu wrote: > > On Wed, Apr 8, 2026 at 4:43 AM Petr Mladek <[email protected]> wrote: > > [...] > > > > > > > > > > This is weird semantic. Which livepatch tag would be allowed to > > > > > supersede it, please? > > > > > > > > > > Do we still need this category? > > > > > > > > It can be superseded by any livepatch that has a non-zero tag set. > > > > > > And this exactly the weird thing. > > > > > > A patch with the .replace flag set is supposed to obsolete all already > > > installed livepatches. It means that it should provide all existing > > > fixes and features. > > > > > > Now, we want to introduce a replace flag/set which would allow to > > > replace/obsolete only the livepatch with the same tag/set number. > > > And we want to prevent conflicts by making sure that livepatches with > > > different tag/set number will never livepatch the same function. > > > > > > Obviously, livepatches with different tag/set number could not > > > obsolete the same no-replace livepatch. They would need to livepatch > > > the same functions touched by the no-replace livepatch and would > > > conflict. > > > > > > So, I suggest to remove the no-replace mode completely. It should > > > not be needed. A livepatch which should be installed in parallel > > > will simply use another unique tag/set number. > > > > I think I see your point now. Existing code works as: > > - replace=false doesn't replace anything > > - replace=true replaces everything > > > > If we assume false=0 and true=1, it is technically possible to define: > > - replace_set=0 doesn't replace anything > > - replace_set=1 replaces everything > > - replace_set=2+ only replace the same replace_set > > Yes. This well describes my point. > > > This is probably a little too complicated. > > > > > > This ensures backward compatibility: while a non-atomic-replace > > > > livepatch can be superseded by an atomic-replace one, the reverse is > > > > not permitted—an atomic-replace livepatch cannot be superseded by a > > > > non-atomic one. > > > > > > IMHO, the backward compatibility would just create complexity and mess > > > in this case. > > > > Given that livepatch is for expert users, I think we can make this work > > without backward compatibility. But breaking compatibility is always not > > preferred. > > I believe that it is acceptable because: > > 1. It was always hard to combine no-replace and replace livepatches. > I wonder if anyone combines them at all.
Because 'replace' patches can supersede 'no-replace' ones, users have to maintain a strict loading order. I doubt anyone actually combines them in production. > > 2. I believe that nobody tries to load the same livepatch module on > different kernel versions. Instead, everyone prepares a custom > livepatch module for each livepatched kernel version/release. Correct. We always build and apply distinct livepatches for each specific kernel version. > > And the tooling for creating livepatches will need to be updated > to use "number" instead of "true/false" anyway. > > That said, it is easier to always use "0" for non-replace patches > instead of assigning an unique "number" to avoid replacing. But > I do not think that this would justify the complexity of having > different semantic for 0, 1, and 2+ replace_set numbers. Fair enough. Let's drop backward compatibility to keep the implementation simple. -- Regards Yafang
