On Tue, Apr 7, 2026 at 8:08 AM Petr Mladek <[email protected]> wrote: [...] > > + * @replace: replace tag: > > + * = 0: Atomic replace is disabled; however, this patch remains > > + * eligible to be superseded by others. > > This is weird semantic. Which livepatch tag would be allowed to > supersede it, please? > > Do we still need this category? > > > + * > 0: Atomic replace is enabled. Only existing patches with a > > + * matching replace tag will be superseded. > > * @list: list node for global list of actively used patches > > * @kobj: kobject for sysfs resources > > * @obj_list: dynamic list of the object entries > > @@ -137,7 +141,7 @@ struct klp_patch { > > struct module *mod; > > struct klp_object *objs; > > struct klp_state *states; > > - bool replace; > > + unsigned int replace; > > This already breaks the backward compatibility by changing the type > and semantic of this field.
I was thinking if replace=0 means no replace, it is still backward compatible. Did I miss something? Thanks, Song > I would also change the name to better > match the new semantic. What about using: > > > * @replace_set: Livepatch using the same @replace_set will get > atomically replaced, see also conflicts[*]. > > unsigned int replace_set; > > [*] A livepatch module, livepatching an already livepatches function, > can be loaded only when it has the same @replace_set number. > > By other words, two livepatches conflict when they have a different > @replace_set number and have at least one livepatched version > in common. [...]
