On Tue, 20 Oct 2015, Chris J Arges wrote: > While I understand why patching __init functions is impossible most of > the time since that memory may already have been freed, and in the > vmlinux case we may never traverse that code patch again. Consider when > we patch __init functions in modules. > > For example, this particular patch fixes an issue in SCTP: > commit 8e2d61e0aed2b7c4ecb35844fe07e0b2b762dee4 > Author: Marcelo Ricardo Leitner <marcelo.leitner@xxxxxxxxx> > Date: Thu Sep 10 17:31:15 2015 -0300 > > sctp: fix race on protocol/netns initialization > > If the sctp module has not yet been loaded, would patching these > __init/__exit functions make sense? > > Are there additional gotchas that need to be addressed in this case? > Would we need to add a flag to patch this only when the module is > unloaded or able to be reloaded? If you need to patch __init function, that implies that the module hasn't yet been loaded, so you might as well patch the on-disk version (before it's actually loaded), and be done. But otherwise you are actually able to patch __init function of the module (and we are doing exactly that) exactly the same way you are patching any other module functions, because we are actually hooked to MODULE_COMING notifier, which triggers before the module actually goes live (i.e. before __init gets executed). -- Jiri Kosina SUSE Labs -- 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
