On Wed, 9 Jan 2019, Petr Mladek wrote: > Replaced patches are removed from the stack when the transition is > finished. It means that Nop structures will never be needed again > and can be removed. Why should we care? > > + Nop structures give the impression that the function is patched > even though the ftrace handler has no effect. > > + Ftrace handlers do not come for free. They cause slowdown that might > be visible in some workloads. The ftrace-related slowdown might > actually be the reason why the function is no longer patched in > the new cumulative patch. One would expect that cumulative patch > would help solve these problems as well. > > + Cumulative patches are supposed to replace any earlier version of > the patch. The amount of NOPs depends on which version was replaced. > This multiplies the amount of scenarios that might happen. > > One might say that NOPs are innocent. But there are even optimized > NOP instructions for different processors, for example, see > arch/x86/kernel/alternative.c. And klp_ftrace_handler() is much > more complicated. > > + It sounds natural to clean up a mess that is no longer needed. > It could only be worse if we do not do it. > > This patch allows to unpatch and free the dynamic structures independently > when the transition finishes. > > The free part is a bit tricky because kobject free callbacks are called > asynchronously. We could not wait for them easily. Fortunately, we do > not have to. Any further access can be avoided by removing them from > the dynamic lists. > > Signed-off-by: Petr Mladek <pmladek@xxxxxxxx> Acked-by: Miroslav Benes <mbenes@xxxxxxx> Miroslav
