On Mon, Jul 13, 2015 at 09:16:28PM +0200, Jiri Kosina wrote: > On Mon, 13 Jul 2015, Jessica Yu wrote: > > > Do you think it would make sense for livepatch to instead establish a > > module dependency requirement between the patch module and the > > to-be-patched module(s), instead of relying on klp_module_notify()? i.e. > > require the target module(s) be loaded before the patch module? Does it > > make sense to apply a patch to a module that hasn't been loaded yet? In > > what use cases would it make sense to patch module code without the > > module itself being loaded? > > I think this is not a good idea, at least if we are targetting distro > vendors as a primary consumers of livepatching infrastructure. > > Consider the (not unlikely) scenario where a bugfix needs to alter core > network driver infrastructure (such as internal netdev API) and perform > corresponding fixups in many networking drivers at the same time. > As a distro vendor, you definitely want to ship this as a single > livepatch, but you absolutely don't want it to cause force modprobing of > every affected network driver on all systems that install that livepatch. That example is pretty much the worst case scenario. But how likely is it really? Have you encountered anything like that with SLES? Live patching of API changes should be avoided as much as possible, and should never be done for exported symbols because of third-party modules. I'm trying to figure out how common this type of issue is, and whether all the added code complexity is really worth it. I'd say the two hairiest parts of livepatch are the module notifier code and the relocation code. We could get rid of both of them if we didn't need to patch unloaded modules. That would make the livepatch code 100% architecture-independent and much cleaner. > At the same time, you really do want to make sure that once the networking > driver gets eventually modprobed any time in the future (for example > network device is hotplugged), it gets patched upon load. I suppose patched versions of the modules could be put on disk, and depmod could be updated to point to them before starting the patching. But that probably creates more headaches. -- Josh -- 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
