[lkml]   [2019]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 2/2] livepatch: Clear relocation targets on a module removal

> > 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

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?


 \ /
  Last update: 2019-09-06 14:52    [W:0.072 / U:1.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site