> > Now, I don't think that replacing .ko on disk is a good idea. We've > > already discussed it. It would lead to a maintenance/packaging problem, > > because you never know which version of the module is loaded in the > > system. The state space grows rather rapidly there. > > What exactly are your concerns? > > Either the old version of the module is loaded, and it's livepatched; or > the new version of the module is loaded, and it's not livepatched. Let's have module foo.ko with function a(). Live patch 1 (LP1) fixes it to a'(), which calls new function b() (present in LP1). LP1 is used only if foo.ko is loaded. foo.ko is replaced with foo'.ko on disk. It contains both a'() (fixed a() to be precise) and new b(). Now there is LP2 with new function c() (or c'(), it does not matter) calling b(). Either foo.ko or foo'.ko can be loaded and you don't know which one. The implementation LP2 would be different in both cases. You could say that it does not matter. If LP2 is implemented for foo.ko, the same could work for foo'.ko (b() would be a part of LP2 and would not be called directly from foo'.ko). LP2 would only be necessarily larger. It is true in case of functions, but if symbol b is not a function but a global variable, it is different then. Moreover, in this case foo'.ko is "LP superset". Meaning that it contains only fixes which are present in LP1. What if it is not. We usually preserve kABI, so there could be a module in two or more versions compiled from slightly different code (older/newer and so on) and you don't know which one is loaded. To be fair we don't allow it (I think) at SUSE except for KMPs (kernel module packages) (the issue of course exists even now and we haven't solved it yet, because it is rare) and out of tree modules which we don't support with LP. It could be solved with srcversion, but it complicates things a lot. "blue sky" idea could extend the issue to all modules given the above is real. Does it make sense? Miroslav
