Re: [PATCH v2] net: Add trace events for all receive exit points

On Mon, 12 Nov 2018 15:46:53 -0500 (EST) Mathieu Desnoyers wrote: > I also notice that in two cases, a "gro_result_t" is implicitly cast > to "int". I usually frown upon this kind of stuff, because it's asking > for trouble if gro_result_t typedef to something else than "int" in the > future. >

Re: [PATCH v2] net: Add trace events for all receive exit points

On Mon, 12 Nov 2018 15:20:55 -0500 (EST) Mathieu Desnoyers wrote: > > Hrm, looking at this again, I notice that there is a single DEFINE_EVENT > using net_dev_template_simple. > > We could simply turn netif_receive_skb_list_exit into a TRACE_EVENT(), > remove the net_dev_template_simple, and

Re: [PATCH v2] net: Add trace events for all receive exit points

nt is the result of the packet > reception or a simple coincidence after further processing by the > thread. > > Signed-off-by: Geneviève Bastien > CC: Mathieu Desnoyers > CC: Steven Rostedt > CC: Ingo Molnar > CC: David S. Miller > --- > Changes in v2: > - Ad

Re: [PATCH] net: Add trace events for all receive exit points

nt is the result of the packet > reception or a simple coincidence after further processing by the > thread. > > Signed-off-by: Geneviève Bastien > CC: Mathieu Desnoyers > CC: Steven Rostedt > CC: Ingo Molnar > CC: David S. Miller > --- > include/trace/events/net.h |

Re: [v8, bpf-next, 4/9] net/wireless/iwlwifi: fix iwlwifi_dev_ucode_error tracepoint

On Thu, 24 May 2018 16:28:39 -0700 Alexei Starovoitov wrote: > Ohh. I didn't realize that networking wireless doesn't fall under netdev. > I thought wireless folks are silent because they are embarrassed > by a function with 17 arguments. Please lets refrain from

Re: Performance regressions in TCP_STREAM tests in Linux 4.15 (and later)

On Mon, 30 Apr 2018 09:14:04 -0700 Ben Greear wrote: > >> As part of VMware's performance testing with the Linux 4.15 kernel, > >> we identified CPU cost and throughput regressions when comparing to > >> the Linux 4.14 kernel. The impacted test cases are mostly

Re: Performance regressions in TCP_STREAM tests in Linux 4.15 (and later)

We'd like this email archived in netdev list, but since netdev is notorious for blocking outlook email as spam, it didn't go through. So I'm replying here to help get it into the archives. Thanks! -- Steve On Fri, 27 Apr 2018 23:05:46 + Michael Wenig wrote: > As part

Re: [PATCH v8 bpf-next 6/9] bpf: introduce BPF_RAW_TRACEPOINT

On Wed, 28 Mar 2018 12:38:48 -0700 Alexei Starovoitov <a...@fb.com> wrote: > On 3/28/18 12:34 PM, Steven Rostedt wrote: > > On Wed, 28 Mar 2018 12:05:37 -0700 > > Alexei Starovoitov <a...@kernel.org> wrote: > > > >> +++ b/include/linux/tracepoint-defs.h

Re: [PATCH v7 bpf-next 06/10] tracepoint: compute num_args at build time

On Wed, 28 Mar 2018 15:32:20 -0400 Steven Rostedt <rost...@goodmis.org> wrote: > -#define __DO_TRACE(tp, proto, args, cond, rcucheck) \ > +#define __DO_TRACE(name, proto, args, cond, rcucheck) &g

Re: [PATCH v8 bpf-next 6/9] bpf: introduce BPF_RAW_TRACEPOINT

On Wed, 28 Mar 2018 12:05:37 -0700 Alexei Starovoitov wrote: > +++ b/include/linux/tracepoint-defs.h > @@ -35,4 +35,10 @@ struct tracepoint { > struct tracepoint_func __rcu *funcs; > }; > > +struct bpf_raw_event_map { > + struct tracepoint *tp; > + void

Re: [PATCH v7 bpf-next 06/10] tracepoint: compute num_args at build time

On Wed, 28 Mar 2018 15:22:24 -0400 (EDT) Mathieu Desnoyers wrote: > > > cache hot/cold argument clearly doesn't apply. > > In the current situation I'm fine with adding this extra field > to struct tracepoint. However, we should keep in mind to move > all

Re: [PATCH v7 bpf-next 06/10] tracepoint: compute num_args at build time

On Wed, 28 Mar 2018 11:19:34 -0700 Alexei Starovoitov <a...@fb.com> wrote: > On 3/28/18 11:10 AM, Steven Rostedt wrote: > > On Wed, 28 Mar 2018 11:03:24 -0700 > > Alexei Starovoitov <a...@fb.com> wrote: > > > >> I can live with this overhead if

Re: [PATCH v7 bpf-next 06/10] tracepoint: compute num_args at build time

On Wed, 28 Mar 2018 11:03:24 -0700 Alexei Starovoitov wrote: > I can live with this overhead if Mathieu insists, > but I prefer to keep it in 'struct tracepoint'. > > Thoughts? I'm fine with keeping it as is. We could probably use it for future enhancements in perf and ftrace.

Re: [PATCH v7 bpf-next 07/10] bpf: introduce BPF_RAW_TRACEPOINT

int. > Multiple bpf_raw_tracepoint_open("xdp_exception", prog_fd) are permitted. > Each with its own bpf program. The kernel will execute > all tracepoint probes and all attached bpf programs. > > In the future bpf_raw_tracepoints can be extended with > query/introspection logic

Re: [PATCH v7 bpf-next 06/10] tracepoint: compute num_args at build time

On Wed, 28 Mar 2018 10:10:34 -0700 Alexei Starovoitov wrote: > > and have: > > > > u64 tp_offset = (u64)tp - (u64)_sdata; > > > > if (WARN_ON(tp_offset > UINT_MAX) > > return -EINVAL; > > > > btp->tp_offset = (u32)tp_offset; > > above math has to be

Re: [PATCH v7 bpf-next 06/10] tracepoint: compute num_args at build time

On Wed, 28 Mar 2018 09:43:56 -0700 Alexei Starovoitov wrote: > > > > Given that only eBPF needs this parameter count, we can move > > it to the struct bpf_raw_event_map newly introduced by Steven, > > right ? This would reduce bloat of struct tracepoint. For instance, > > we don't

Re: [PATCH v6 bpf-next 08/11] bpf: introduce BPF_RAW_TRACEPOINT

On Tue, 27 Mar 2018 17:51:55 -0700 Alexei Starovoitov wrote: > Turned out it was in init.data section and got poisoned. > this fixes it: > @@ -258,6 +258,7 @@ > LIKELY_PROFILE()\ > BRANCH_PROFILE()

Re: [PATCH v6 bpf-next 08/11] bpf: introduce BPF_RAW_TRACEPOINT

On Tue, 27 Mar 2018 14:58:24 -0400 Steven Rostedt <rost...@goodmis.org> wrote: > +extern struct bpf_raw_event_map *__start__bpf_raw_tp[]; > +extern struct bpf_raw_event_map *__stop__bpf_raw_tp[]; > + > +struct bpf_raw_event_map *bpf_find_raw_tracepoint(const char *name) &

Re: [PATCH v2 bpf-next] bpf, tracing: unbreak lttng

On Tue, 27 Mar 2018 11:39:19 +0200 Daniel Borkmann <dan...@iogearbox.net> wrote: > On 03/27/2018 02:07 AM, Steven Rostedt wrote: > > On Mon, 26 Mar 2018 16:02:20 -0700 > > Alexei Starovoitov <a...@kernel.org> wrote: > > > >> for_each_kernel_tracep

Re: [PATCH v6 bpf-next 08/11] bpf: introduce BPF_RAW_TRACEPOINT

[ Added Andrew Morton too ] On Tue, 27 Mar 2018 15:00:41 -0400 Steven Rostedt <rost...@goodmis.org> wrote: > On Tue, 27 Mar 2018 11:45:34 -0700 > Alexei Starovoitov <a...@fb.com> wrote: > > > >> + > > >> +snprintf(buf, sizeof(buf), &quo

Re: [PATCH v6 bpf-next 08/11] bpf: introduce BPF_RAW_TRACEPOINT

On Tue, 27 Mar 2018 15:00:41 -0400 Steven Rostedt <rost...@goodmis.org> wrote: > > Wasting extra 8bytes * number_of_tracepoints just for lack of trust > > in kallsyms doesn't sound like good trade off to me. > > If kallsyms are inaccurate all sorts of things will break

Re: [PATCH v6 bpf-next 08/11] bpf: introduce BPF_RAW_TRACEPOINT

On Tue, 27 Mar 2018 11:45:34 -0700 Alexei Starovoitov wrote: > >> + > >> + snprintf(buf, sizeof(buf), "__bpf_trace_%s", tp->name); > >> + addr = kallsyms_lookup_name(buf); > >> + if (!addr) > >> + return -ENOENT; > >> + > >> + return tracepoint_probe_register(tp, (void

Re: [PATCH v6 bpf-next 08/11] bpf: introduce BPF_RAW_TRACEPOINT

On Tue, 27 Mar 2018 13:11:43 -0400 Steven Rostedt <rost...@goodmis.org> wrote: > On Tue, 27 Mar 2018 13:02:11 -0400 > Steven Rostedt <rost...@goodmis.org> wrote: > > > Honestly, I think this is too much of a short cut and a hack. I know > > you want to keep it

Re: [PATCH v6 bpf-next 08/11] bpf: introduce BPF_RAW_TRACEPOINT

On Tue, 27 Mar 2018 13:02:11 -0400 Steven Rostedt <rost...@goodmis.org> wrote: > Honestly, I think this is too much of a short cut and a hack. I know > you want to keep it "simple" and save space, but you really should do > it the same way ftrace and perf do it.

Re: [PATCH v6 bpf-next 08/11] bpf: introduce BPF_RAW_TRACEPOINT

On Mon, 26 Mar 2018 19:47:03 -0700 Alexei Starovoitov wrote: > Ctrl-C of tracing daemon or cmdline tool that uses this feature > will automatically detach bpf program, unload it and > unregister tracepoint probe. > > On the kernel side for_each_kernel_tracepoint() is used You

Re: [PATCH v6 bpf-next 06/11] tracepoint: compute num_args at build time

check safety of bpf program access that > is coming in subsequent patch. > > Signed-off-by: Alexei Starovoitov <a...@kernel.org> Reviewed-by: Steven Rostedt (VMware) <rost...@goodmis.org> -- Steve > --- > include/linux/tracepoint-defs.h | 1 + > include/l

Re: [PATCH v6 bpf-next 07/11] tracepoint: introduce kernel_tracepoint_find_by_name

gt; > >> From: Alexei Starovoitov <a...@kernel.org> > >> > >> introduce kernel_tracepoint_find_by_name() helper to let bpf core > >> find tracepoint by name and later attach bpf probe to a tracepoint > >> > >> Signed-off-by: Alexei St

Re: [PATCH v6 bpf-next 07/11] tracepoint: introduce kernel_tracepoint_find_by_name

t; > Signed-off-by: Alexei Starovoitov <a...@kernel.org> Reviewed-by: Steven Rostedt (VMware) <rost...@goodmis.org> Thanks for doing this Alexei! One nit below. > --- > include/linux/tracepoint.h | 6 ++ > kernel/tracepoint.c| 9 + > 2 files cha

Re: [PATCH bpf-next] bpf, tracing: unbreak lttng

On Mon, 26 Mar 2018 15:35:56 -0700 Alexei Starovoitov wrote: > > This patch is not reverting to the old code properly. It introduces a > > static inline void function that returns NULL. Please compile-test > > with CONFIG_TRACEPOINTS=n before submitting a patch involving

Re: [PATCH v2 bpf-next] bpf, tracing: unbreak lttng

On Mon, 26 Mar 2018 16:02:20 -0700 Alexei Starovoitov wrote: > for_each_kernel_tracepoint() is used by out-of-tree lttng module > and therefore cannot be changed. This is false and misleading. NACK. -- Steve > Instead introduce kernel_tracepoint_find_by_name() to find >

Re: [PATCH bpf-next] bpf, tracing: unbreak lttng

On Mon, 26 Mar 2018 15:25:32 -0700 Alexei Starovoitov <a...@fb.com> wrote: > On 3/26/18 3:15 PM, Steven Rostedt wrote: > > On Mon, 26 Mar 2018 15:08:45 -0700 > > Alexei Starovoitov <a...@kernel.org> wrote: > > > >> for_each_kernel_tracep

Re: [PATCH bpf-next] bpf, tracing: unbreak lttng

On Mon, 26 Mar 2018 15:08:45 -0700 Alexei Starovoitov wrote: > for_each_kernel_tracepoint() is used by out-of-tree lttng module > and therefore cannot be changed. > Instead introduce kernel_tracepoint_find_by_name() to find > tracepoint by name. > > Fixes: 9e9afbae6514

Re: [PATCH v5 bpf-next 06/10] tracepoint: compute num_args at build time

On Mon, 26 Mar 2018 11:39:05 -0700 Alexei Starovoitov <a...@fb.com> wrote: > On 3/26/18 11:11 AM, Steven Rostedt wrote: > > On Mon, 26 Mar 2018 10:55:51 -0700 > > Alexei Starovoitov <a...@fb.com> wrote: > > > >> An email ago you were ok to s/return/re

Re: [PATCH v5 bpf-next 06/10] tracepoint: compute num_args at build time

On Mon, 26 Mar 2018 10:55:51 -0700 Alexei Starovoitov wrote: > An email ago you were ok to s/return/return NULL/ in your out-of-tree > module, but now flip flop to add new function approach just to > reduce the work you need to do in lttng? > We're not talking about changing

Re: [PATCH v5 bpf-next 06/10] tracepoint: compute num_args at build time

On Mon, 26 Mar 2018 09:47:21 -0700 Alexei Starovoitov wrote: > I don't mind to _rename_ for_each_kernel_tracepoint() into > tracepoint_find_by_name(), but keeping exported function > just to be used by out-of-tree modules would be wrong message for > the kernel community in general.

Re: [PATCH v5 bpf-next 06/10] tracepoint: compute num_args at build time

On Mon, 26 Mar 2018 09:25:07 -0700 Alexei Starovoitov wrote: > commit log of patch 6 states: > > "for_each_tracepoint_range() api has no users inside the kernel. > Make it more useful with ability to stop for_each() loop depending > via callback return value. > In such form it's

Re: [PATCH v5 bpf-next 06/10] tracepoint: compute num_args at build time

On Mon, 26 Mar 2018 11:56:15 -0400 Steven Rostedt <rost...@goodmis.org> wrote: > On Fri, 23 Mar 2018 19:30:34 -0700 > Alexei Starovoitov <a...@fb.com> wrote: > > > +static void *for_each_tracepoint_range(struct tracepoint * const *begin, > > +

Re: [PATCH v5 bpf-next 00/10] bpf, tracing: introduce bpf raw tracepoints

On Mon, 26 Mar 2018 09:00:33 -0700 Alexei Starovoitov <a...@fb.com> wrote: > On 3/26/18 8:47 AM, Steven Rostedt wrote: > > On Mon, 26 Mar 2018 17:32:02 +0200 > > Daniel Borkmann <dan...@iogearbox.net> > >> On 03/26/2018 05:04 PM, Steven Rostedt wrote: >

Re: [PATCH v5 bpf-next 06/10] tracepoint: compute num_args at build time

On Fri, 23 Mar 2018 19:30:34 -0700 Alexei Starovoitov wrote: > +static void *for_each_tracepoint_range(struct tracepoint * const *begin, > +struct tracepoint * const *end, > +void *(*fct)(struct tracepoint *tp,

Re: [PATCH v5 bpf-next 00/10] bpf, tracing: introduce bpf raw tracepoints

On Mon, 26 Mar 2018 17:32:02 +0200 Daniel Borkmann <dan...@iogearbox.net> wrote: > On 03/26/2018 05:04 PM, Steven Rostedt wrote: > > On Mon, 26 Mar 2018 10:28:03 +0200 > > Daniel Borkmann <dan...@iogearbox.net> wrote: > > > >>> tracepointbase

Re: [PATCH v5 bpf-next 00/10] bpf, tracing: introduce bpf raw tracepoints

On Mon, 26 Mar 2018 10:28:03 +0200 Daniel Borkmann wrote: > > tracepointbase kprobe+bpf tracepoint+bpf raw_tracepoint+bpf > > task_rename 1.1M 769K947K1.0M > > urandom_read 789K 697K750K755K > > Applied to bpf-next,

Re: [PATCH v5 bpf-next 06/10] tracepoint: compute num_args at build time

On Fri, 23 Mar 2018 19:30:34 -0700 Alexei Starovoitov wrote: > From: Alexei Starovoitov > > add fancy macro to compute number of arguments passed into tracepoint > at compile time and store it as part of 'struct tracepoint'. > The number is necessary to check

Re: [PATCH v2 bpf-next 5/8] bpf: introduce BPF_RAW_TRACEPOINT

On Sat, 24 Mar 2018 00:13:28 +0100 Daniel Borkmann wrote: > #define UNPACK(...) __VA_ARGS__ > #define REPEAT_1(FN, DL, X, ...) FN(X) > #define REPEAT_2(FN, DL, X, ...) FN(X) UNPACK DL REPEAT_1(FN, DL, > __VA_ARGS__) > #define REPEAT_3(FN, DL, X,

Re: [PATCH v3 bpf-next 01/10] treewide: remove struct-pass-by-value from tracepoints arguments

On Thu, 22 Mar 2018 12:31:12 -0700 Alexei Starovoitov <a...@fb.com> wrote: > On 3/22/18 11:11 AM, Steven Rostedt wrote: > > On Thu, 22 Mar 2018 11:01:48 -0700 > > Alexei Starovoitov <a...@fb.com> wrote: > > > >> From: Alexei Starovoitov <a...@kerne

Re: [PATCH v3 bpf-next 01/10] treewide: remove struct-pass-by-value from tracepoints arguments

On Thu, 22 Mar 2018 11:01:48 -0700 Alexei Starovoitov wrote: > From: Alexei Starovoitov > > Fix all tracepoint arguments to pass structures (large and small) by reference > instead of by value. > Avoiding passing large structs by value is a good coding style. >

Re: [PATCH v2 bpf-next 4/8] tracepoint: compute num_args at build time

On Thu, 22 Mar 2018 08:51:16 -0700 Alexei Starovoitov wrote: > So I definitely support the idea of build time warn for large > number of args. I'm more for a build time error for large number of args. -- Steve

Re: [PATCH v2 bpf-next 4/8] tracepoint: compute num_args at build time

On Wed, 21 Mar 2018 15:05:46 -0700 Alexei Starovoitov wrote: > Like the only reason my patch is counting till 17 is because of > trace_iwlwifi_dev_ucode_error(). > The next offenders are using 12 arguments: > trace_mc_event() > trace_mm_vmscan_lru_shrink_inactive() > > Clearly not

Re: [PATCH 3/3] tracing: Rewrite filter logic to be simpler and faster

On Fri, 9 Mar 2018 22:15:23 -0500 Steven Rostedt <rost...@goodmis.org> wrote: > Sorry for the spam. A little more spam ;-) I know what happened, as I'm able to recreate it. For those that use claws-mail, be careful. I clicked on the email I wanted to reply to. Then I must have hit

Re: [PATCH 3/3] tracing: Rewrite filter logic to be simpler and faster

logic on literals in min()/max()". Sorry for the spam. -- Steve On Fri, 9 Mar 2018 22:10:19 -0500 Steven Rostedt <rost...@goodmis.org> wrote: > On Fri, 09 Mar 2018 21:34:45 -0500 > Steven Rostedt <rost...@goodmis.org> wrote: > > > 2 files changed, 1050 insert

Re: [PATCH 3/3] tracing: Rewrite filter logic to be simpler and faster

On Fri, 09 Mar 2018 21:34:45 -0500 Steven Rostedt <rost...@goodmis.org> wrote: > 2 files changed, 1050 insertions(+), 1273 deletions(-) BTW, it's a bit bigger impact than 223 deletions. As I added a lot of comments to explain the logic better. Removing comments and white s

Re: [PATCH 0/3] Remove accidental VLA usage

On Thu, 8 Mar 2018 09:02:36 -0600 Josh Poimboeuf wrote: > On Wed, Mar 07, 2018 at 07:30:44PM -0800, Kees Cook wrote: > > This series adds SIMPLE_MAX() to be used in places where a stack array > > is actually fixed, but the compiler still warns about VLA usage due to > >

Re: [PATCH bpf-next 0/5] bpf, tracing: introduce bpf raw tracepoints

On Mon, 5 Mar 2018 14:36:07 +0100 Daniel Borkmann wrote: > Ping, Peter/Steven. If you have a chance, please review the series. You're not off my radar, but I'm doing a lot of traveling for the next two weeks (started last week). I'll see if I can find some time to look at

Re: [RFC PATCH bpf-next v2 1/4] tracing/kprobe: bpf: Check error injectable event is on function entry

On Wed, 27 Dec 2017 19:45:42 -0800 Alexei Starovoitov wrote: > I don't think that's the case. My reading of current > trace_kprobe_ftrace() -> arch_check_ftrace_location() > is that it will not be true for old mcount case. In the old mcount case, you can't use ftrace to return

Re: [PATCH net-next v4.1 5/6] net: dccp: Add DCCP sendmsg trace event

On Thu, 21 Dec 2017 10:57:36 -0500 (EST) David Miller wrote: > When you fix any part of a patch series, you must always repost the > entire series from scratch, not just the patch(s) that change. He probably gets that from me. I don't usually require a full series if only a

Re: [PATCH net-next v4 0/6] net: tcp: sctp: dccp: Replace jprobe usage with trace events

On Thu, 21 Dec 2017 11:36:57 +0900 Masami Hiramatsu wrote: > On Wed, 20 Dec 2017 14:24:24 -0500 (EST) > David Miller wrote: > > > From: David Miller > > Date: Wed, 20 Dec 2017 14:20:40 -0500 (EST) > > > > > From: Masami

Re: [PATCH -tip v3 3/6] net: sctp: Add SCTP ACK tracking trace event

On Tue, 19 Dec 2017 17:58:25 +0900 Masami Hiramatsu wrote: > +TRACE_EVENT(sctp_probe, > + > + TP_PROTO(const struct sctp_endpoint *ep, > + const struct sctp_association *asoc, > + struct sctp_chunk *chunk), > + > + TP_ARGS(ep, asoc, chunk),

Re: [PATCH 3/3] trace: print address if symbol not found

On Tue, 19 Dec 2017 14:00:11 +1100 "Tobin C. Harding" wrote: > I ran through these as outlined here for the new version (v4). This hits > the modified code but doesn't test symbol look up failure. stacktrace shouldn't post non kernel values, unless there's a frame pointer that

Re: [PATCH 3/3] trace: print address if symbol not found

On Tue, 19 Dec 2017 08:16:14 +1100 "Tobin C. Harding" wrote: > > > #endif /* _LINUX_KERNEL_TRACE_H */ > > > diff --git a/kernel/trace/trace_events_hist.c > > > b/kernel/trace/trace_events_hist.c > > > index 1e1558c99d56..3e28522a76f4 100644 > > > ---

Re: [PATCH 1/3] kallsyms: don't leak address when symbol not found

On Tue, 19 Dec 2017 09:41:29 +1100 "Tobin C. Harding" wrote: > Current suggestion on list is to remove this function. Do you have a use > case in mind where debugging will break? We could add a fix to this > series if so. Otherwise next version will likely drop >

Re: [v2 PATCH -tip 3/6] net: sctp: Add SCTP ACK tracking trace event

On Mon, 18 Dec 2017 17:12:15 +0900 Masami Hiramatsu wrote: > Add SCTP ACK tracking trace event to trace the changes of SCTP > association state in response to incoming packets. > It is used for debugging SCTP congestion control algorithms, > and will replace sctp_probe

Re: [PATCH 3/3] trace: print address if symbol not found

On Mon, 18 Dec 2017 10:53:32 +1100 "Tobin C. Harding" wrote: > Fixes behaviour modified by: commit bd6b239cdbb2 ("kallsyms: don't leak > address when symbol not found") > > Previous patch changed behaviour of kallsyms function sprint_symbol() to > return an error code instead of

Re: [PATCH] bpf: Fix compile warnings when !CONFIG_BPF_SYSCALL

On Fri, 1 Dec 2017 12:06:05 -0700 Jason Gunthorpe wrote: > Such as: > > In file included from ./include/trace/events/xdp.h:10:0, > from ./include/linux/bpf_trace.h:6, > from drivers/net/ethernet/intel/i40e/i40e_txrx.c:29: >

Re: [PATCH V11 2/5] vsprintf: refactor %pK code out of pointer()

On Wed, 29 Nov 2017 15:27:46 +1100 "Tobin C. Harding" <m...@tobin.cc> wrote: > On Tue, Nov 28, 2017 at 09:39:57PM -0500, Steven Rostedt wrote: > > On Wed, 29 Nov 2017 13:05:02 +1100 > > "Tobin C. Harding" <m...@tobin.cc> wrote: > > > >

Re: [PATCH V11 2/5] vsprintf: refactor %pK code out of pointer()

On Wed, 29 Nov 2017 13:05:02 +1100 "Tobin C. Harding" wrote: > + /* > + * kptr_restrict==1 cannot be used in IRQ context > + * because its test for CAP_SYSLOG would be meaningless. > + */ > + if (in_irq() ||

Re: [PATCH] tcp: Export to userspace the TCP state names for the trace events

On Sat, 11 Nov 2017 02:06:00 + Yafang Shao <laoar.s...@gmail.com> wrote: > 2017-11-10 15:07 GMT+00:00 Steven Rostedt <rost...@goodmis.org>: > > On Fri, 10 Nov 2017 12:56:06 +0800 > > Yafang Shao <laoar.s...@gmail.com> wrote: > > > >

Re: [PATCH] tcp: Export to userspace the TCP state names for the trace events

On Fri, 10 Nov 2017 12:56:06 +0800 Yafang Shao wrote: > Could the macro tcp_state_name() be renamed ？ > If is included in include/net/tcp.h, it will Ideally, you don't want to include trace/events/*.h headers in other headers, as they can have side effects if those

[PATCH] tcp: Export to userspace the TCP state names for the trace events

From: "Steven Rostedt (VMware)" <rost...@goodmis.org> The TCP trace events (specifically tcp_set_state), maps emums to symbol names via __print_symbolic(). But this only works for reading trace events from the tracefs trace files. If perf or trace-cmd were to record these e

Re: [PATCH] net/tcp: introduce TRACE_EVENT for TCP/IPv4 state transition

On Thu, 9 Nov 2017 23:40:13 + Song Liu wrote: > > tcp_set_state uses __print_symbolic to show state in text format. I found > > trace-cmd cannot parse that part: > > > > [011] 147338.660560: tcp_set_state:sport=16262 dport=48346 \ > >saddr=127.0.0.6

Re: [PATCH] net/tcp: introduce TRACE_EVENT for TCP/IPv4 state transition

On Thu, 9 Nov 2017 15:43:29 +0900 Alexei Starovoitov wrote: > > +TRACE_EVENT(tcp_set_state, > > + TP_PROTO(struct sock *sk, int oldstate, int newstate), > > + TP_ARGS(sk, oldstate, newstate), > > + > > + TP_STRUCT__entry( > > + __field(__be32, dst) >

Re: [PATCH] kallsyms: don't leak address when printing symbol

On Thu, 9 Nov 2017 16:45:48 +1100 "Tobin C. Harding" <m...@tobin.cc> wrote: > On Wed, Nov 08, 2017 at 10:35:55PM -0500, Steven Rostedt wrote: > > On Thu, 9 Nov 2017 12:50:29 +1100 > > "Tobin C. Harding" <m...@tobin.cc> wrote: > >

Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl

On Thu, 9 Nov 2017 10:24:32 +0530 Kaiwan N Billimoria wrote: > On Thu, Nov 9, 2017 at 10:13 AM, Kaiwan N Billimoria > wrote: > >> But I don't know if there is anything else than the profiling code > >> that _really_ wants access to

Re: [PATCH] kallsyms: don't leak address when printing symbol

On Thu, 9 Nov 2017 12:50:29 +1100 "Tobin C. Harding" wrote: > Currently if a pointer is printed using %p[ssB] and the symbol is not > found (kallsyms_lookup() fails) then we print the actual address. This > leaks kernel addresses. We should instead print something _safe_. > >

Re: [PATCH v3] scripts: add leaking_addresses.pl

On Tue, 7 Nov 2017 13:44:01 -0800 Linus Torvalds wrote: > > Looking other places that stand out, it seems like > > /proc/lockdep_chains and /proc/lockdep (CONFIG_LOCKDEP=y) has a ton of > > %p usage. It's unclear to me if a hash is sufficient for meaningful > >

Re: [PATCH net-next] ipv6: let trace_fib6_table_lookup() dereference the fib table

caller. > > Let's the tracing code pay this overhead, passing to the trace > helper the table pointer. This gives small but measurable > performance improvement under UDP flood. > > Signed-off-by: Paolo Abeni <pab...@redhat.com> > --- Acked-by: Steven Rostedt (VMware) <rost...@goodmis.org> -- Steve

Re: [PATCH] tracing: bpf: Hide bpf trace events when they are not used

On Mon, 16 Oct 2017 21:11:06 +0100 (WEST) David Miller <da...@davemloft.net> wrote: > From: Steven Rostedt <rost...@goodmis.org> > Date: Mon, 16 Oct 2017 16:01:25 -0400 > > > On Mon, 16 Oct 2017 20:54:34 +0100 (WEST) > > David Miller <da...@davemloft.net>

Re: [PATCH] tracing: bpf: Hide bpf trace events when they are not used

On Mon, 16 Oct 2017 20:54:34 +0100 (WEST) David Miller wrote: > Steven, I lost track of how this patch is being handled. > > Do you want me to merge it via my net-next tree? If you want. I could take it too if you give me an ack. It's not dependent on any other changes so

Re: [PATCH] tracing: bpf: Hide bpf trace events when they are not used

On Thu, 12 Oct 2017 18:38:36 -0700 Alexei Starovoitov wrote: > actually just noticed that xdp tracepoints are not covered by ifdef. > They depend on bpf_syscall too. So probably makes sense to wrap > them together. > bpf tracepoints are not being actively worked on

Re: [PATCH] tracing: bpf: Hide bpf trace events when they are not used

On Thu, 12 Oct 2017 18:14:52 -0700 Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Thu, Oct 12, 2017 at 06:40:02PM -0400, Steven Rostedt wrote: > > From: Steven Rostedt (VMware) <rost...@goodmis.org> > > > > All the trace events defined in in

[PATCH] tracing: bpf: Hide bpf trace events when they are not used

From: Steven Rostedt (VMware) <rost...@goodmis.org> All the trace events defined in include/trace/events/bpf.h are only used when CONFIG_BPF_SYSCALL is defined. But this file gets included by include/linux/bpf_trace.h which is included by the networking code with CREATE_TRACE_POINTS d

Re: [PATCH 1/4] rcu: introduce noref debug

On Fri, 6 Oct 2017 14:57:46 +0200 Paolo Abeni wrote: > We currently lack a debugging infrastructure to ensure that > long-lived noref dst are properly handled - namely dropped > or converted to a refcounted version before escaping the current > RCU section. > > This

Re: [PATCH net] bpf: one perf event close won't free bpf program attached by another perf event

On Thu, 21 Sep 2017 13:17:06 +0200 Peter Zijlstra wrote: > I suspect that would break a fair bunch of bpf proglets, since the data > access to the trace data would be completely different, but it would be > much nicer to not have this distinction based on event type. Maybe

Re: [PATCH net] bpf: one perf event close won't free bpf program attached by another perf event

On Mon, 18 Sep 2017 16:38:36 -0700 Yonghong Song wrote: > This patch fixes a bug exhibited by the following scenario: > 1. fd1 = perf_event_open with attr.config = ID1 > 2. attach bpf program prog1 to fd1 > 3. fd2 = perf_event_open with attr.config = ID1 > > 4. user

Re: [PATCH 02/12] trace: Make trace_hwlat timestamp y2038 safe

+4,6 @@ > * Copyright (C) 2008 Red Hat Inc, Steven Rostedt <srost...@redhat.com> > * > */ > - > #include > #include > #include > @@ -1161,11 +1160,11 @@ trace_hwlat_print(struct trace_iterator *iter, int > flags, > > trace_assign_type(fi

Re: [PATCH v3] tracing/kprobes: expose maxactive for kretprobe in kprobe_events

On Tue, 4 Apr 2017 20:24:59 +0900 Masami Hiramatsu wrote: > On Mon, 3 Apr 2017 12:36:22 +0200 > Alban Crequy wrote: > > > From: Alban Crequy > > > > When a kretprobe is installed on a kernel function, there is a maximum > >

Re: [PATCH v2] tracing/kprobes: expose maxactive for kretprobe in kprobe_events

> > # of undefined(test bug): 0 > > BugLink: https://github.com/iovisor/bcc/issues/1072 > Signed-off-by: Alban Crequy <al...@kinvolk.io> > > --- > > Changes since v1: > - Remove "(*)" from documentation. (Review from Masami Hiramatsu) > - F

Re: [PATCH v1] tracing/kprobes: expose maxactive for kretprobe in kprobe_events

On Wed, 29 Mar 2017 00:23:35 +0900 Masami Hiramatsu wrote: > > @@ -598,8 +601,10 @@ static int create_trace_kprobe(int argc, char **argv) > > { > > /* > > * Argument syntax: > > -* - Add kprobe: p[:[GRP/]EVENT] [MOD:]KSYM[+OFFS]|KADDR [FETCHARGS] > > -* -

Re: [PATCH v1] tracing/kprobes: expose maxactive for kretprobe in kprobe_events

"[PATCH v1]" I like your confidence, or lack of, that there isn't going to be a v2 or v3 ;-) Masami, what do you think of this? -- Steve On Tue, 28 Mar 2017 15:52:22 +0200 Alban Crequy wrote: > When a kretprobe is installed on a kernel function, there is a maximum >

[PATCH] netfilter: Force fake conntrack entry to be at least 8 bytes aligned

smp_apic_timer_interrupt+0x2a/0x34 apic_timer_interrupt+0x37/0x3c By using DEFINE/DECLARE_PER_CPU_ALIGNED we can enforce at least 8 byte alignment as all cache line sizes are at least 8 bytes or more. Fixes: a9e419dc7be6 ("netfilter: merge ctinfo into nfct pointer storage area") Signed-off-by: Steven Roste

Re: [PATCH net-next 1/3] trace: add variant without spacing in trace_print_hex_seq

ose that reuses > trace_print_hex_seq(). > > Signed-off-by: Daniel Borkmann <dan...@iogearbox.net> > Cc: Steven Rostedt <rost...@goodmis.org> > Cc: Arnaldo Carvalho de Melo <a...@redhat.com> > --- > include/linux/trace_events.h | 3 ++- > include/trace/t

Re: [PATCH net-next 2/3] lib, traceevent: add PRINT_HEX_STR variant

earbox.net> > Cc: Steven Rostedt <rost...@goodmis.org> > Cc: Arnaldo Carvalho de Melo <a...@redhat.com> > --- I haven't tested it, but it looks fine with me: Acked-by: Steven Rostedt (VMware) <rost...@goodmis.org> -- Steve

Re: [PATCH v3] net/phy: add trace events for mdio accesses

On Tue, 22 Nov 2016 16:47:11 +0100 Uwe Kleine-König <u...@kleine-koenig.org> wrote: > Make it possible to generate trace events for mdio read and write accesses. > > Signed-off-by: Uwe Kleine-König <u...@kleine-koenig.org> For the tracing side. Acked-by: Steven Rostedt

Re: [PATCH v2] net/phy: add trace events for mdio accesses

On Tue, 22 Nov 2016 11:01:27 +0100 Uwe Kleine-König wrote: > diff --git a/include/trace/events/mdio.h b/include/trace/events/mdio.h > new file mode 100644 > index ..468e2d095d19 > --- /dev/null > +++ b/include/trace/events/mdio.h > @@ -0,0 +1,42 @@ > +#undef

Re: [PATCH] net/phy: add trace events for mdio accesses

On Mon, 14 Nov 2016 12:03:35 +0100 Uwe Kleine-König wrote: > Make it possible to generate trace events for mdio read and write accesses. > > Signed-off-by: Uwe Kleine-König > --- > drivers/net/phy/mdio_bus.c | 15 +++ >

Re: [PATCH 249/249] net:ethernet:intel:igb_main.c: Add Throttling disable option in order to decrease latency usually required by RT applications.

On Tue, 6 Sep 2016 13:17:04 + Amir Yihie wrote: > I guess there's not much to do here? -- Steve

Re: [RT PATCH 2/2] net: add a lock around icmp_sk()

On Wed, 31 Aug 2016 09:37:43 -0700 Eric Dumazet wrote: > On Wed, 2016-08-31 at 18:00 +0200, Sebastian Andrzej Siewior wrote: > > It looks like the this_cpu_ptr() access in icmp_sk() is protected with > > local_bh_disable(). To avoid missing serialization in -RT I am

Re: [RT PATCH 1/2] net: add back the missing serialization in ip_send_unicast_reply()

On Wed, 31 Aug 2016 18:00:48 +0200 Sebastian Andrzej Siewior wrote: > Some time ago Sami Pietikäinen reported a crash on -RT in > ip_send_unicast_reply() which was later fixed by Nicholas Mc Guire > (v3.12.8-rt11). Later (v3.18.8) the code was reworked and I dropped the >

Re: [4.4-RT PATCH RFC/RFT] drivers: net: cpsw: mark rx/tx irq as IRQF_NO_THREAD

On Thu, 11 Aug 2016 19:15:40 +0300 Grygorii Strashko wrote: > Mark CPSW Rx/Tx IRQs as IRQF_NO_THREAD and avoid double scheduling on -RT > where this IRQs are forced threaded: > rx-irq > |- schedule threaded rx-irq handler > ... > |- threaded rx-irq handler ->

Re: [PATCH 1084/1285] Replace numeric parameter like 0444 with macro

On Tue, 2 Aug 2016 20:15:02 +0800 Baole Ni wrote: > I find that the developers often just specified the numeric value > when calling a macro which is defined with a parameter for access permission. > As we know, these numeric value for access permission have had the >

Re: [PATCH 1083/1285] Replace numeric parameter like 0444 with macro

On Tue, 2 Aug 2016 20:14:55 +0800 Baole Ni wrote: > I find that the developers often just specified the numeric value > when calling a macro which is defined with a parameter for access permission. > As we know, these numeric value for access permission have had the >

Re: [patch net-next 2/2] devlink: fix trace format string

On Thu, 14 Jul 2016 10:07:38 -0700 Randy Dunlap wrote: > On 07/14/16 02:37, Jiri Pirko wrote: > > From: Arnd Bergmann > > > > Including devlink.h on ARM and probably other 32-bit architectures results > > in > > a harmless warning: > > > > In file

  1   2   >