> > > > Second, unrelated patches must never patch the same functions. > > > > Otherwise we would not be able to define which implementation > > > > should be used. This is especially important when a patch is > > > > removed and we need to fallback either to another patch or > > > > original code. Yes, it makes perfect sense. But it needs code > > > > that will check it, refuse loading the patch, ... It is not > > > > complicated. But it is rather additional code than > > > > simplification. I might make livepatching more safe > > > > but probably not simplify the code. > > > > > > We don't need to enforce that. The func stack can stay. If somebody > > > wants to patch the same function multiple times (without using > > > 'replace'), that's inadvisable, but it's also their business. They're > > > responsible for the tooling to ensure the patch stack order is sane. > > > > > > While it might make sense to ignore the patch stack (ordering) for > > the enable operation. Do we really want to ignore it when disabling > > a patch. > > > > By other words, do we want to allow disabling a patch that is in > > the middle of the stack, only partly in use? Does not this allow > > some other crazy scenarios? Is it really the user business? > > Will it make our life easier? > > If there's no longer a patch stack, then there's no concept of a middle. > We would expect the patches to be independent of one another, and so > disabling any of them independently would be harmless. > > If any of the patches share a func, and the user disables one in the > "middle", it's not our job to support that. The vendor / patch author > should prevent such cases from occurring with tooling, packaging, > documentation, etc. Or they can just use 'replace'. > > We can already have similar unexpected situations today. For example, > what if patch B is a cumulative superset of patch A, but the user > mistakenly loads patch A (without replace) *after* loading patch B? > Then some unforeseen craziness could ensue. > > We can't control all such scenarios (and that's ok), but we shouldn't > pretend that we support them. FWIW I agree with the above. Provided we keep the func stack. [...] > > The question is what to do with the stack of patches. It will have > > no meaning for the enable operation because it will be done > > automatically. But what about the disable/unregistrer operation? > > Assuming we got rid of the patch stack, would we even need to keep a > global list of patches anymore? There are places we walk through the list of patches (klp_add_nops() in this patch set, klp_module_coming()), so probably yes. Miroslav -- 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
