On 01/30/2018 09:03 AM, Petr Mladek wrote: > On Fri 2018-01-26 14:29:36, Evgenii Shatokhin wrote: >> >> In my experience, it was quite convenient sometimes to just "replace all >> binary patches the user currently has loaded with this single one". No >> matter what these original binary patches did and where they came from. > > To be honest, I would feel better if the livepatch framework is > more safe. It should prevent breaking the system by a patch > that atomically replaces other random patches that rely on callbacks. > > Well, combining random livepatches from random vendors is a call > for troubles. It might easily fail when two patches add > different changes to the same function. > > I wonder if we should introduce some tags, keys, vendors. I mean > to define an identification or dependencies that would say that some > patches are compatible or incompatible. > > We could allow to livepatch one function by two livepatches > only if they are from the same vendor. But then the order still > might be important. Also I am not sure if this condition is safe > enough. > > One the other hand, we could handle callbacks like the shadow > variables. Every shadow variable has an ID. We have an API to > add/read/update/remove them. We might allow to have more > callbacks with different IDs. Then we could run callbacks > only for IDs that are newly added or removed. Sigh, this would > be very complex implementation as well. But it might make > these features easier to use and maintain. Interesting ideas, but I wonder if this could be accomplished at the livepatch module level? ie, leave it to kpatch-build (or a livepatch equivalent) to produce a module that does this automatically. I guess it would then be completely opt-in checking, but transfers the complexity out of the kernel livepatching core. I don't see a simple way to provide flexibility of when/if calling redundant callbacks without making the code even more complicated. I don't have any use-cases off hand that would require such features, but I guess if I did absolutely needed them, I might be inclined to say prepare ahead of time and write callbacks so that they may be disabled externally -- either by a new livepatch module's init() or some other means. Then whatever crazy policy I need is contained to my modules, not provided or enforced by the kernel. -- Joe -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
