Messages in this thread | | | Date | Thu, 18 Jun 2020 10:50:51 +0900 | From | Masami Hiramatsu <> | Subject | Re: [PATCH] tracing/boottime: Fix kprobe multiple events |
| |
Hi,
On Wed, 17 Jun 2020 16:08:17 +0200 Sascha Ortmann <sascha.ortmann@stud.uni-hannover.de> wrote:
> Fix boottime kprobe events to add multiple events even if one fails > and report probe generation failures. > > As an example, when we try to set multiprobe kprobe events in > bootconfig like this: > > ftrace.event.kprobes.vfsevents { > probes = "vfs_read $arg1 $arg2,, > !error! not reported;?", // leads to error > "vfs_write $arg1 $arg2" > } > > this will not work like expected. After commit > da0f1f4167e3af69e1d8b32d6d65195ddd2bfb64 ("tracing/boottime: > Fix kprobe event API usage"), the function > trace_boot_add_kprobe_event will not produce any error message, > aborting the function and stopping subsequent probes from getting > installed when adding a probe fails at kprobe_event_gen_cmd_start.
Ah, good catch! Indeed, I missed the error message.
> Furthermore, probes continue when kprobe_event_gen_cmd_end fails > (and kprobe_event_gen_cmd_start did not fail). In this case the > function even returns successfully when the last call to > kprobe_event_gen_cmd_end is successful. > > The behaviour of reporting and aborting after failures is not > consistent.
OK. And for more consistency, we should abort the loop if we hit any error instead of continuing, because if trace_boot_add_kprobe_event() returns an error code, the rest of event settings are skipped. (See trace_boot_init_one_event())
> > The function trace_boot_add_kprobe_event now continues even when > one of the multiple events fails. Each failure is now reported > individually. Since the function can only return one result to the > caller, the function returns now the last failure (or none, if > nothing fails). > > Cc: linux-kernel@i4.cs.fau.de > Signed-off-by: Maximilian Werner <maximilian.werner96@gmail.com> > Signed-off-by: Sascha Ortmann <sascha.ortmann@stud.uni-hannover.de> > --- > kernel/trace/trace_boot.c | 16 +++++++++++----- > 1 file changed, 11 insertions(+), 5 deletions(-) > > diff --git a/kernel/trace/trace_boot.c b/kernel/trace/trace_boot.c > index 9de29bb45a27..dbb50184e060 100644 > --- a/kernel/trace/trace_boot.c > +++ b/kernel/trace/trace_boot.c > @@ -95,18 +95,24 @@ trace_boot_add_kprobe_event(struct xbc_node *node, const char *event) > struct xbc_node *anode; > char buf[MAX_BUF_LEN]; > const char *val; > + int error = 0; > int ret = 0; > > xbc_node_for_each_array_value(node, "probes", anode, val) { > kprobe_event_cmd_init(&cmd, buf, MAX_BUF_LEN); > > - ret = kprobe_event_gen_cmd_start(&cmd, event, val); > - if (ret) > - break; > + error = kprobe_event_gen_cmd_start(&cmd, event, val); > + if (error) { > + pr_err("Failed to generate probe: %s\n", buf); > + ret = error; > + continue;
so, could you break here?
> + } > > - ret = kprobe_event_gen_cmd_end(&cmd); > - if (ret) > + error = kprobe_event_gen_cmd_end(&cmd); > + if (error) { > pr_err("Failed to add probe: %s\n", buf); > + ret = error;
And here.
> + } > } > > return ret; > -- > 2.17.1 >
Thank you!
-- Masami Hiramatsu <mhiramat@kernel.org>
| |