On Mon, Feb 16, 2015 at 6:26 AM, He Kuang wrote:
> Hi, Alexei
>
> Another suggestion on bpf syscall interface. Currently, BPF +
> syscalls/kprobes depends on CONFIG_BPF_SYSCALL. In kernel used on
> commercial products, CONFIG_BPF_SYSCALL is probably disabled, in this
> case, bpf bytecode cannot
On Mon, Feb 16, 2015 at 6:26 AM, He Kuang heku...@huawei.com wrote:
Hi, Alexei
Another suggestion on bpf syscall interface. Currently, BPF +
syscalls/kprobes depends on CONFIG_BPF_SYSCALL. In kernel used on
commercial products, CONFIG_BPF_SYSCALL is probably disabled, in this
case, bpf
Hi, Alexei
Another suggestion on bpf syscall interface. Currently, BPF +
syscalls/kprobes depends on CONFIG_BPF_SYSCALL. In kernel used on
commercial products, CONFIG_BPF_SYSCALL is probably disabled, in this
case, bpf bytecode cannot be loaded to the kernel.
If we turn the functionality of
Hi, Alexei
Another suggestion on bpf syscall interface. Currently, BPF +
syscalls/kprobes depends on CONFIG_BPF_SYSCALL. In kernel used on
commercial products, CONFIG_BPF_SYSCALL is probably disabled, in this
case, bpf bytecode cannot be loaded to the kernel.
If we turn the functionality of
On Wed, Feb 11, 2015 at 11:58 PM, Hekuang wrote:
>
>>> eBPF is very flexible, which means it is bound to have someone use it
>>> in a way you never dreamed of, and that will be what bites you in the
>>> end (pun intended).
>>
>> understood :)
>> let's start slow then with bpf+syscall and
On Wed, Feb 11, 2015 at 7:51 AM, Steven Rostedt wrote:
> On Tue, 10 Feb 2015 22:33:05 -0800
> Alexei Starovoitov wrote:
>
>
>> fair enough.
>> Something like TRACE_MARKER(arg1, arg2) that prints
>> it was hit without accessing the args would be enough.
>> Without any args it is indeed a 'fast
On Wed, Feb 11, 2015 at 5:28 AM, Peter Zijlstra wrote:
>
> We're compiling the BPF stuff against the 'current' kernel headers
> right?
the tracex1 example is pulling kernel headers to demonstrate
how bpf_fetch*() helpers can be used to walk kernel structures
without debug info.
The other
On Wed, Feb 11, 2015 at 11:58 PM, Hekuang heku...@huawei.com wrote:
eBPF is very flexible, which means it is bound to have someone use it
in a way you never dreamed of, and that will be what bites you in the
end (pun intended).
understood :)
let's start slow then with bpf+syscall and
On Wed, Feb 11, 2015 at 5:28 AM, Peter Zijlstra pet...@infradead.org wrote:
We're compiling the BPF stuff against the 'current' kernel headers
right?
the tracex1 example is pulling kernel headers to demonstrate
how bpf_fetch*() helpers can be used to walk kernel structures
without debug info.
On Wed, Feb 11, 2015 at 7:51 AM, Steven Rostedt rost...@goodmis.org wrote:
On Tue, 10 Feb 2015 22:33:05 -0800
Alexei Starovoitov a...@plumgrid.com wrote:
fair enough.
Something like TRACE_MARKER(arg1, arg2) that prints
it was hit without accessing the args would be enough.
Without any args
eBPF is very flexible, which means it is bound to have someone use it
in a way you never dreamed of, and that will be what bites you in the
end (pun intended).
understood :)
let's start slow then with bpf+syscall and bpf+kprobe only.
I think BPF + system calls/kprobes can meet our use case
On Tue, 10 Feb 2015 22:33:05 -0800
Alexei Starovoitov wrote:
> fair enough.
> Something like TRACE_MARKER(arg1, arg2) that prints
> it was hit without accessing the args would be enough.
> Without any args it is indeed a 'fast kprobe' only.
> Debug info would still be needed to access
>
On Tue, Feb 10, 2015 at 04:53:59PM -0500, Steven Rostedt wrote:
> > >> In the future we might add a tracepoint and pass a single
> > >> pointer to interesting data struct to it. bpf programs will walk
> > >> data structures 'as safe modules' via bpf_fetch*() methods
> > >> without exposing it as
On Tue, Feb 10, 2015 at 04:22:50PM -0800, Alexei Starovoitov wrote:
> > It would need to do more that that. It may have to calculate the value
> > that it returns, as the internal value may be different with different
> > kernels.
>
> back to 'prio'... the 'prio' accessible from the program
>
On Tue, Feb 10, 2015 at 04:22:50PM -0800, Alexei Starovoitov wrote:
> well, ->prio and ->pid are already printed by sched tracepoints
> and their meaning depends on scheduler. So users taking that
> into account.
Right, so trace_events were/are root only, and root 'should' be in the
root pid
On Tue, Feb 10, 2015 at 04:22:50PM -0800, Alexei Starovoitov wrote:
> >> not all tools use libtraceevent.
> >> gdb calls perf_event_open directly:
> >> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/nat/linux-btrace.c
> >> and parses PERF_RECORD_SAMPLE as a binary.
> >> In
On Tue, Feb 10, 2015 at 04:53:59PM -0500, Steven Rostedt wrote:
In the future we might add a tracepoint and pass a single
pointer to interesting data struct to it. bpf programs will walk
data structures 'as safe modules' via bpf_fetch*() methods
without exposing it as ABI.
Will
On Tue, Feb 10, 2015 at 04:22:50PM -0800, Alexei Starovoitov wrote:
not all tools use libtraceevent.
gdb calls perf_event_open directly:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/nat/linux-btrace.c
and parses PERF_RECORD_SAMPLE as a binary.
In this case it's
On Tue, Feb 10, 2015 at 04:22:50PM -0800, Alexei Starovoitov wrote:
well, -prio and -pid are already printed by sched tracepoints
and their meaning depends on scheduler. So users taking that
into account.
Right, so trace_events were/are root only, and root 'should' be in the
root pid
On Tue, Feb 10, 2015 at 04:22:50PM -0800, Alexei Starovoitov wrote:
It would need to do more that that. It may have to calculate the value
that it returns, as the internal value may be different with different
kernels.
back to 'prio'... the 'prio' accessible from the program
should be
On Tue, 10 Feb 2015 22:33:05 -0800
Alexei Starovoitov a...@plumgrid.com wrote:
fair enough.
Something like TRACE_MARKER(arg1, arg2) that prints
it was hit without accessing the args would be enough.
Without any args it is indeed a 'fast kprobe' only.
Debug info would still be needed to
eBPF is very flexible, which means it is bound to have someone use it
in a way you never dreamed of, and that will be what bites you in the
end (pun intended).
understood :)
let's start slow then with bpf+syscall and bpf+kprobe only.
I think BPF + system calls/kprobes can meet our use case
On Tue, Feb 10, 2015 at 8:31 PM, Steven Rostedt wrote:
>> > Again, this would mean they become invisible to ftrace, and even
>> > ftrace_dump_on_oops.
>>
>> yes, since these new tracepoints have no meat inside them.
>> They're placeholders sitting idle and waiting for bpf to do
>> something
On Tue, 10 Feb 2015 19:04:55 -0800
Alexei Starovoitov wrote:
> > You mean to be completely invisible to ftrace? And the debugfs/tracefs
> > directory?
>
> I mean it will be seen in tracefs to get 'id', but without
> enable/format/filter
In other words, invisible to ftrace. I'm not sure I'll
On Tue, Feb 10, 2015 at 4:50 PM, Steven Rostedt wrote:
>
>> >> But some maintainers think of them as ABI, whereas others
>> >> are using them freely. imo it's time to remove ambiguity.
>> >
>> > I would love to, and have brought this up at Kernel Summit more than
>> > once with no solution out of
On Tue, 10 Feb 2015 16:22:50 -0800
Alexei Starovoitov wrote:
> > Yep, and if this becomes a standard, then any change that makes
> > trace_pipe different will be reverted.
>
> I think reading of trace_pipe is widespread.
I've heard of a few, but nothing that has broken when something changed.
On Tue, Feb 10, 2015 at 1:53 PM, Steven Rostedt wrote:
> On Tue, 10 Feb 2015 11:53:22 -0800
> Alexei Starovoitov wrote:
>
>> On Tue, Feb 10, 2015 at 5:05 AM, Steven Rostedt wrote:
>> > On Mon, 9 Feb 2015 22:10:45 -0800
>> > Alexei Starovoitov wrote:
>> >
>> >> One can argue that current
On Tue, 10 Feb 2015 11:53:22 -0800
Alexei Starovoitov wrote:
> On Tue, Feb 10, 2015 at 5:05 AM, Steven Rostedt wrote:
> > On Mon, 9 Feb 2015 22:10:45 -0800
> > Alexei Starovoitov wrote:
> >
> >> One can argue that current TP_printk format is already an ABI,
> >> because somebody might be
On Tue, Feb 10, 2015 at 5:05 AM, Steven Rostedt wrote:
> On Mon, 9 Feb 2015 22:10:45 -0800
> Alexei Starovoitov wrote:
>
>> One can argue that current TP_printk format is already an ABI,
>> because somebody might be parsing the text output.
>
> If somebody does, then it is an ABI. Luckily, it's
On Mon, 9 Feb 2015 22:10:45 -0800
Alexei Starovoitov wrote:
> One can argue that current TP_printk format is already an ABI,
> because somebody might be parsing the text output.
If somebody does, then it is an ABI. Luckily, it's not that useful to
parse, thus it hasn't been an issue. As Linus
On Mon, 9 Feb 2015 21:51:05 -0800
Alexei Starovoitov wrote:
> On Mon, Feb 9, 2015 at 8:46 PM, Steven Rostedt wrote:
> >
> > Looks like this is entirely perf based and does not interact with
> > ftrace at all. In other words, it's perf not tracing.
> >
> > It makes more sense to go through tip
On Tue, Feb 10, 2015 at 4:50 PM, Steven Rostedt rost...@goodmis.org wrote:
But some maintainers think of them as ABI, whereas others
are using them freely. imo it's time to remove ambiguity.
I would love to, and have brought this up at Kernel Summit more than
once with no solution out
On Tue, 10 Feb 2015 19:04:55 -0800
Alexei Starovoitov a...@plumgrid.com wrote:
You mean to be completely invisible to ftrace? And the debugfs/tracefs
directory?
I mean it will be seen in tracefs to get 'id', but without
enable/format/filter
In other words, invisible to ftrace. I'm not
On Tue, 10 Feb 2015 11:53:22 -0800
Alexei Starovoitov a...@plumgrid.com wrote:
On Tue, Feb 10, 2015 at 5:05 AM, Steven Rostedt rost...@goodmis.org wrote:
On Mon, 9 Feb 2015 22:10:45 -0800
Alexei Starovoitov a...@plumgrid.com wrote:
One can argue that current TP_printk format is already
On Tue, Feb 10, 2015 at 5:05 AM, Steven Rostedt rost...@goodmis.org wrote:
On Mon, 9 Feb 2015 22:10:45 -0800
Alexei Starovoitov a...@plumgrid.com wrote:
One can argue that current TP_printk format is already an ABI,
because somebody might be parsing the text output.
If somebody does, then
On Tue, Feb 10, 2015 at 8:31 PM, Steven Rostedt rost...@goodmis.org wrote:
Again, this would mean they become invisible to ftrace, and even
ftrace_dump_on_oops.
yes, since these new tracepoints have no meat inside them.
They're placeholders sitting idle and waiting for bpf to do
something
On Tue, Feb 10, 2015 at 1:53 PM, Steven Rostedt rost...@goodmis.org wrote:
On Tue, 10 Feb 2015 11:53:22 -0800
Alexei Starovoitov a...@plumgrid.com wrote:
On Tue, Feb 10, 2015 at 5:05 AM, Steven Rostedt rost...@goodmis.org wrote:
On Mon, 9 Feb 2015 22:10:45 -0800
Alexei Starovoitov
On Mon, 9 Feb 2015 22:10:45 -0800
Alexei Starovoitov a...@plumgrid.com wrote:
One can argue that current TP_printk format is already an ABI,
because somebody might be parsing the text output.
If somebody does, then it is an ABI. Luckily, it's not that useful to
parse, thus it hasn't been an
On Mon, 9 Feb 2015 21:51:05 -0800
Alexei Starovoitov a...@plumgrid.com wrote:
On Mon, Feb 9, 2015 at 8:46 PM, Steven Rostedt rost...@goodmis.org wrote:
Looks like this is entirely perf based and does not interact with
ftrace at all. In other words, it's perf not tracing.
It makes more
On Tue, 10 Feb 2015 16:22:50 -0800
Alexei Starovoitov a...@plumgrid.com wrote:
Yep, and if this becomes a standard, then any change that makes
trace_pipe different will be reverted.
I think reading of trace_pipe is widespread.
I've heard of a few, but nothing that has broken when
On Mon, Feb 9, 2015 at 9:13 PM, Steven Rostedt wrote:
>> \
>> + if (prog) { \
>> + __maybe_unused const u64 z = 0; \
>> +
On Mon, Feb 9, 2015 at 8:46 PM, Steven Rostedt wrote:
>
> Looks like this is entirely perf based and does not interact with
> ftrace at all. In other words, it's perf not tracing.
>
> It makes more sense to go through tip than the tracing tree.
well, all of earlier series were based on ftrace
On Mon, 9 Feb 2015 19:45:54 -0800
Alexei Starovoitov wrote:
> +/* For tracepoint filters argN fields match one to one to arguments
> + * passed to tracepoint events
> + *
> + * For syscall entry filters argN fields match syscall arguments
> + * For syscall exit filters arg1 is a return value
>
On Mon, 9 Feb 2015 19:45:54 -0800
Alexei Starovoitov wrote:
> +#endif /* _LINUX_KERNEL_BPF_TRACE_H */
> diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
> index 139b5067345b..4c275ce2dcf0 100644
> --- a/include/trace/ftrace.h
> +++ b/include/trace/ftrace.h
> @@ -17,6 +17,7 @@
> */
On Mon, Feb 9, 2015 at 8:46 PM, Steven Rostedt rost...@goodmis.org wrote:
Looks like this is entirely perf based and does not interact with
ftrace at all. In other words, it's perf not tracing.
It makes more sense to go through tip than the tracing tree.
well, all of earlier series were
On Mon, Feb 9, 2015 at 9:13 PM, Steven Rostedt rost...@goodmis.org wrote:
\
+ if (prog) { \
+ __maybe_unused const u64 z = 0; \
+
On Mon, 9 Feb 2015 19:45:54 -0800
Alexei Starovoitov a...@plumgrid.com wrote:
+#endif /* _LINUX_KERNEL_BPF_TRACE_H */
diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 139b5067345b..4c275ce2dcf0 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -17,6
On Mon, 9 Feb 2015 19:45:54 -0800
Alexei Starovoitov a...@plumgrid.com wrote:
+/* For tracepoint filters argN fields match one to one to arguments
+ * passed to tracepoint events
+ *
+ * For syscall entry filters argN fields match syscall arguments
+ * For syscall exit filters arg1 is a
48 matches
Mail list logo
