| Message ID | 20190312110437.5977-1-qais.yousef@arm.com |
|---|---|
| State | RFC |
| Delegated to: | David Miller |
| Headers | show |
| Series | [RFC] Export supported trace features in debugfs | expand |
On 03/12/19 11:07, Qais Yousef wrote: > eBPF tools like bcc-tools have hard time figuring out when features like > raw_tracepoint are supported in the kernel on which we are running. At > the moment a fragile mechanism of matching bpf_find_raw_tracepoint() > function in /proc/kallsyms is used to find out whether raw tracepoints > can be used or not. But when this function was renamed recently to > bpf_get_raw_tracepoint() the tool started to fail to use raw > tracepoints. > > To help in providing a more reliable way to detect features like > RAW_TRACEPOINT, add a new file in trace debugfs to export the supported > features. > > $cat /sys/kernel/debug/tracing/supported_features > RAW_TRACEPOINT > EXAMPLE_FEATURE_1 > EXAMPLE_FEATURE_2 > > Signed-off-by: Qais Yousef <qais.yousef@arm.com> > --- > > This is a half baked patch to probe the potential of this solution. > > The breakage mentioned in the commit message is here: > > https://github.com/iovisor/bcc/pull/2241/commits/0f5849187972a50adf0d9eaa8788c11f9fd926ea > > I am not sure what else beside raw_tracepoint makes sense to expose right now. > > kernel/trace/trace.c | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c > index c4238b441624..daae09238e62 100644 > --- a/kernel/trace/trace.c > +++ b/kernel/trace/trace.c > @@ -6670,6 +6670,28 @@ static const struct file_operations snapshot_raw_fops = { > > #endif /* CONFIG_TRACER_SNAPSHOT */ > > +#define TRACE_FEATURE(feat)__stringify(feat) "\n" > + > +#define TRACE_FEATURES\ > +TRACE_FEATURE(RAW_TRACEPOINT)\ > +TRACE_FEATURE(EXAMPLE_FEATUTE_1)\ > +TRACE_FEATURE(EXAMPLE_FEATUTE_2) > + > +static ssize_t > +tracing_read_trace_features(struct file *filp, char __user *ubuf, > +size_t cnt, loff_t *ppos) > +{ > +char *buf = TRACE_FEATURES; > +size_t len = sizeof(TRACE_FEATURES); > + > +return simple_read_from_buffer(ubuf, cnt, ppos, buf, len); > +} > + > +static const struct file_operations show_trace_features_fops = { > +.read = tracing_read_trace_features, > +.llseek = no_llseek, > +}; > + > static int tracing_buffers_open(struct inode *inode, struct file *filp) > { > struct trace_array *tr = inode->i_private; > @@ -8242,6 +8264,9 @@ static __init int tracer_init_tracefs(void) > &ftrace_update_tot_cnt, &tracing_dyn_info_fops); > #endif > > +trace_create_file("trace_features", 0444, d_tracer, > +NULL, &show_trace_features_fops); > + > create_trace_instances(d_tracer); > > update_tracer_options(&global_trace); > -- > 2.17.1 > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. Apologies that shouldn't have appeared. I can resend the patch if it matters. -- Qais Yousef
On Tue, Mar 12, 2019 at 11:07:14AM +0000, Qais Yousef wrote: > eBPF tools like bcc-tools have hard time figuring out when features like > raw_tracepoint are supported in the kernel on which we are running. At > the moment a fragile mechanism of matching bpf_find_raw_tracepoint() > function in /proc/kallsyms is used to find out whether raw tracepoints > can be used or not. But when this function was renamed recently to > bpf_get_raw_tracepoint() the tool started to fail to use raw > tracepoints. > > To help in providing a more reliable way to detect features like > RAW_TRACEPOINT, add a new file in trace debugfs to export the supported > features. > > $cat /sys/kernel/debug/tracing/supported_features > RAW_TRACEPOINT > EXAMPLE_FEATURE_1 > EXAMPLE_FEATURE_2 > > Signed-off-by: Qais Yousef <qais.yousef@arm.com> this type of attempts have been made in the past and we always rejected them. Please use 'bpftool' instead that detects numerous bpf related features including raw_tp. # bpftool feature probe|grep raw_tracepoint eBPF program_type raw_tracepoint is available
On 03/12/19 08:27, Alexei Starovoitov wrote: > On Tue, Mar 12, 2019 at 11:07:14AM +0000, Qais Yousef wrote: > > eBPF tools like bcc-tools have hard time figuring out when features like > > raw_tracepoint are supported in the kernel on which we are running. At > > the moment a fragile mechanism of matching bpf_find_raw_tracepoint() > > function in /proc/kallsyms is used to find out whether raw tracepoints > > can be used or not. But when this function was renamed recently to > > bpf_get_raw_tracepoint() the tool started to fail to use raw > > tracepoints. > > > > To help in providing a more reliable way to detect features like > > RAW_TRACEPOINT, add a new file in trace debugfs to export the supported > > features. > > > > $cat /sys/kernel/debug/tracing/supported_features > > RAW_TRACEPOINT > > EXAMPLE_FEATURE_1 > > EXAMPLE_FEATURE_2 > > > > Signed-off-by: Qais Yousef <qais.yousef@arm.com> > > this type of attempts have been made in the past and we always rejected them. > Please use 'bpftool' instead that detects numerous bpf related features including raw_tp. > # bpftool feature probe|grep raw_tracepoint > eBPF program_type raw_tracepoint is available > I see. I should have looked harder. I'll have a look at what bpftool does then. Thanks -- Qais Yousef
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index c4238b441624..daae09238e62 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -6670,6 +6670,28 @@ static const struct file_operations snapshot_raw_fops = { #endif /* CONFIG_TRACER_SNAPSHOT */ +#define TRACE_FEATURE(feat)__stringify(feat) "\n" + +#define TRACE_FEATURES\ +TRACE_FEATURE(RAW_TRACEPOINT)\ +TRACE_FEATURE(EXAMPLE_FEATUTE_1)\ +TRACE_FEATURE(EXAMPLE_FEATUTE_2) + +static ssize_t +tracing_read_trace_features(struct file *filp, char __user *ubuf, +size_t cnt, loff_t *ppos) +{ +char *buf = TRACE_FEATURES; +size_t len = sizeof(TRACE_FEATURES); + +return simple_read_from_buffer(ubuf, cnt, ppos, buf, len); +} + +static const struct file_operations show_trace_features_fops = { +.read = tracing_read_trace_features, +.llseek = no_llseek, +}; + static int tracing_buffers_open(struct inode *inode, struct file *filp) { struct trace_array *tr = inode->i_private; @@ -8242,6 +8264,9 @@ static __init int tracer_init_tracefs(void) &ftrace_update_tot_cnt, &tracing_dyn_info_fops); #endif +trace_create_file("trace_features", 0444, d_tracer, +NULL, &show_trace_features_fops); + create_trace_instances(d_tracer); update_tracer_options(&global_trace);
eBPF tools like bcc-tools have hard time figuring out when features like raw_tracepoint are supported in the kernel on which we are running. At the moment a fragile mechanism of matching bpf_find_raw_tracepoint() function in /proc/kallsyms is used to find out whether raw tracepoints can be used or not. But when this function was renamed recently to bpf_get_raw_tracepoint() the tool started to fail to use raw tracepoints. To help in providing a more reliable way to detect features like RAW_TRACEPOINT, add a new file in trace debugfs to export the supported features. $cat /sys/kernel/debug/tracing/supported_features RAW_TRACEPOINT EXAMPLE_FEATURE_1 EXAMPLE_FEATURE_2 Signed-off-by: Qais Yousef <qais.yousef@arm.com> --- This is a half baked patch to probe the potential of this solution. The breakage mentioned in the commit message is here: https://github.com/iovisor/bcc/pull/2241/commits/0f5849187972a50adf0d9eaa8788c11f9fd926ea I am not sure what else beside raw_tracepoint makes sense to expose right now. kernel/trace/trace.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) -- 2.17.1 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.