On 06/28, Masami Hiramatsu wrote:
>
> @@ -232,19 +246,21 @@ enable_trace_probe(struct trace_probe *tp, struct
> ftrace_event_file *file)
> rcu_assign_pointer(tp->files, new);
> tp->flags |= TP_FLAG_TRACE;
>
> + ret = __enable_trace_probe(tp);
> + if (ret < 0) {
> + /* Write back the old list */
> + rcu_assign_pointer(tp->files, old);
> + old = new; /* "new" must be freed */
> + }
> +
> if (old) {
> /* Make sure the probe is done with old files */
> synchronize_sched();
> kfree(old);
> }
Ah, but this conflicts with the other changes I sent. They have
your acks, and iiuc Steven is going to apply them.
Besides, this fix is not complete afaics, we should also clear
TP_FLAG_TRACE/PROFILE if __enable_trace_probe() fails.
Perhaps you can do this later, on top of the pending changes?
Or. Given that this patch assumes that enable_kprobe() must succed,
can't we make a minimal change for now?
-------------------------------------------------------------------------------
[PATCH] tracing/kprobe: WARN() if enable_kprobe() fails.
enable_trace_probe() doesn't recover tp->files/flags if enable_kprobe()
fails, this looks confusing.
However, enable_kprobe() must not fail at this time except for unknown
bug or changing the implementation of enable_kprobe(), because usual
failure cases (not registered or gone) are already filtered.
So this patch simply adds WARN_ON(ret) to document this fact, even if
it makes sense to cleanup the logic anyway later.
Reported-by: Srikar Dronamraju <sri...@linux.vnet.ibm.com>
Signed-off-by: Oleg Nesterov <o...@redhat.com>
---
kernel/trace/trace_kprobe.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 5c070db..bb608b5 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -220,6 +220,7 @@ enable_trace_probe(struct trace_probe *tp, struct
ftrace_event_file *file)
ret = enable_kretprobe(&tp->rp);
else
ret = enable_kprobe(&tp->rp.kp);
+ WARN_ON(ret);
}
out:
return ret;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
