search

dynup / kpatch

kpatch - live kernel patching
GNU General Public License v2.0
1.49k stars 305 forks source link

Get rid of "external" dynrelas #556

Closed jpoimboe closed 1 year ago

jpoimboe commented 8 years ago

As described here:

https://lkml.kernel.org/r/20151112191917.GJ4038@treble.hsd1.ky.comcast.net

flaming-toast commented 8 years ago

I'm probably misunderstanding the mailing list thread, but I'm slightly confused about how this is going to be implemented. Say the external flags aren't used anymore both in dynrelas and livepatch code. Given a klp_reloc with just the name, sympos, type, etc., how will livepatch know where to look for the symbol? (the three options being, it's either exported and global, in another .o in the patch module and global, or in the object itself which could be local or global)

jpoimboe commented 8 years ago

Here's my understanding. Let me know if this makes sense.

We'll have to provide the name of the object (objname) where the symbol lives. kpatch will need a little bit of rework for that.

  1. If it's "external" and in Module.symvers, we know it's exported. We can find the objname in Module.symvers. sympos should always be 0 because exported symbols are global, and globals are unique.
  2. Otherwise, if it's "external" and not in Module.symvers, we know it must be in another .o in the patch module. objname will be the patch module name, and sympos will be 0 (we can probably get by with not supporting duplicate symbols for this rare case).
flaming-toast commented 8 years ago

Ah, that makes sense now.

It sounds like dynrelas would just need another field that contains the objname where the symbol (referenced by the dynrela) might live, and create-diff-object probably needs another argument for the path to Module.symvers. Doesn't sound too bad. Then we could just replace the "external" logic in livepatch with a single klp_find_object_symbol() call. I can work on this if there isn't someone working on it already.

jpoimboe commented 8 years ago

Sounds good!