Messages in this thread |  | | Date | Tue, 7 Jan 2020 18:39:07 -0500 | From | Steven Rostedt <> | Subject | Re: [BUGFIX PATCH] kprobes: Fix to cancel optimizing/unoptimizing kprobes correctly |
| |
On Tue, 7 Jan 2020 23:42:24 +0900 Masami Hiramatsu <mhiramat@kernel.org> wrote:
> optimize_kprobe() and unoptimize_kprobe() cancels if given kprobe > is on the optimizing_list or unoptimizing_list. However, since > commit f66c0447cca1 ("kprobes: Set unoptimized flag after > unoptimizing code") modified the update timing of the > KPROBE_FLAG_OPTIMIZED, it doesn't work as expected anymore. > > The optimized_kprobe could be following states. > > - [optimizing]: Before inserting jump instruction > op.kp->flags has KPROBE_FLAG_OPTIMIZED and > op->list is not empty. > > - [optimized]: jump inserted > op.kp->flags has KPROBE_FLAG_OPTIMIZED and > op->list is empty. > > - [unoptimizing]: Before removing jump instruction (including unused > optprobe) > op.kp->flags has KPROBE_FLAG_OPTIMIZED and > op->list is not empty. > > - [unoptimized]: jump removed > op.kp->flags doesn't have KPROBE_FLAG_OPTIMIZED and > op->list is empty. > > Current code mis-expects [unoptimizing] state doesn't have > KPROBE_FLAG_OPTIMIZED, and that can cause wrong results. > > This introduces optprobe_queued_unopt() to distinguish [optimizing] > and [unoptimizing] states and fixes logics in optimize_kprobe() and > unoptimize_kprobe(). > > Fixes: f66c0447cca1 ("kprobes: Set unoptimized flag after unoptimizing code") > Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Looks good.
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> return; > } > + > /* Optimized kprobe case */ > - if (force) > + if (force) { > /* Forcibly update the code: this is a special case */ > force_unoptimize_kprobe(op); > - else { > + } else { > list_add(&op->list, &unoptimizing_list); > kick_kprobe_optimizer(); > }
I see you added some clean up to this patch.
-- Steve
|  |