On Wed 2019-02-13 10:27:08, Nicolai Stange wrote: > Petr Mladek <pmladek@xxxxxxxx> writes: > So do I understand you correctly that you would disallow reversing the > patch application transition for sticky live patches? > > Because if the transition happens to not complete, it's a bug anyway and > there's still the 'force' mechanism an admin could use as a last resort? Exactly. > Sounds about right to me. Uff :-) > > > That said, I do not want to over-engineer it. On the other hand, > > I do not see anything complex if we introduce a helper that > > would be able to set the sticky flag in the callback, e.g. > > > > /* The next operation could not get reverted. */ > > klp_set_patch_sticky(obj); > > Yes, that looks nice. > > One corner case which should probably get documented is that of the > non-effect of klp_set_patch_sticky() from a pre-patch callback returning > non-zero, right? Good question. One effect is that it would disable revert even when the sticky flag was not set statically. It makes sense. The flag is set by the problematic code. But you probably ask what should happen when any later pre-patch callback or klp_patch_object fails. The damage is done and could not get fully reverted. On the other hand, the system is obviously able to run even without the patch being applied. It brings another question if a sticky livepatch module can get removed from the system. I mean if some code might still need to be used (registered somewhere by the callback). It is actually one usecase. The pre-patch callback might add a hook somewhere to temporary handle the transition state, e.g. probe, int3 handler. It might get removed once the transition is complete. Best Regards, Petr
