Re: lockups with netconsole on e1000 on media insertion

On Fri, 2005-08-05 at 13:45 +0200, Andi Kleen wrote: John Bäckstrand [EMAIL PROTECTED] writes: I've been trying to hunt down a hard lockup issue with some hardware of mine, but I've possibly hit a kernel bug instead. When using netconsole on my e1000, if I unplug the cable and then

Re: lockups with netconsole on e1000 on media insertion

On Fri, 2005-08-05 at 15:55 +0200, Andi Kleen wrote: This is fixing the symptom and is not the cure. Unfortunately I don't have a e1000 card so I can't try a fix. But I did have a e100 card that would lock up the same way. The problem was that netpoll_poll calls the cards netpoll routine

Re: lockups with netconsole on e1000 on media insertion

On Fri, 2005-08-05 at 16:14 +0200, Andi Kleen wrote: On Fri, Aug 05, 2005 at 10:10:13AM -0400, Steven Rostedt wrote: On Fri, 2005-08-05 at 15:55 +0200, Andi Kleen wrote: This is fixing the symptom and is not the cure. Unfortunately I don't have a e1000 card so I can't try a fix. But I

Re: lockups with netconsole on e1000 on media insertion

On Fri, 2005-08-05 at 07:36 -0700, David S. Miller wrote: From: Steven Rostedt [EMAIL PROTECTED] Date: Fri, 05 Aug 2005 10:27:06 -0400 Darn it, since this should really be reported. Yes, the core netpoll should bail out, but it is also a problem with the driver and should be fixed. I

Re: [PATCH] netpoll can lock up on low memory.

On Fri, 2005-08-05 at 14:28 -0700, Matt Mackall wrote: Netpoll generally must assume it won't get a second chance, as it's being called by things like oops() and panic() and used by things like kgdb. If netpoll fails, the box is dead anyway. But it is also being called by every printk in

Re: [PATCH] netpoll can lock up on low memory.

On Fri, 2005-08-05 at 23:26 +0200, Andi Kleen wrote: I suspect Steven's patch for the e1000 is needed in addition to handle different cases too. I haven't tested it. Someone with a e1000 must see if it works. I submitted the e100 fix that had the same problem, but I would feel better if the

Re: [PATCH] netpoll can lock up on low memory.

On Fri, 2005-08-05 at 18:53 -0700, Matt Mackall wrote: On Fri, Aug 05, 2005 at 08:23:55PM -0400, Steven Rostedt wrote: [...] If you need to really get the data out, then the design should be changed. Have some return value showing the failure, check for oops_in_progress or whatever

Re: [PATCH] netpoll can lock up on low memory.

On Sat, 2005-08-06 at 02:46 -0700, David S. Miller wrote: Can you guys stop peeing your pants over this, put aside your differences, and work on a mutually acceptable fix for these bugs? Much appreciated, thanks :-) In my last email, I stated that this discussion seems to have demonstrated

Re: [PATCH -rt DO NOT APPLY] Fix for tg3 networking lockup

On Thu, 3 Aug 2006, Theodore Tso wrote: On Thu, Aug 03, 2006 at 02:48:45PM -0700, David Miller wrote: eth0: Tigon3 [partno(BCM95704s) rev 2100 PHY(serdes)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:14:5e:86:44:24 The 5704 chip will set TG3_FLAG_TAGGED_STATUS, and therefore

Re: [PATCH -rt DO NOT APPLY] Fix for tg3 networking lockup

On Sun, 6 Aug 2006, David Miller wrote: From: Steven Rostedt [EMAIL PROTECTED] Date: Mon, 7 Aug 2006 01:34:56 -0400 (EDT) My suggestion would be to separate that tg3_timer into 4 different timers, which is what it actually looks like. Timers have non-trivial cost. It's cheaper to have

Re: [PATCH -rt DO NOT APPLY] Fix for tg3 networking lockup

On Tue, 8 Aug 2006, Steven Rostedt wrote: On Sun, 6 Aug 2006, David Miller wrote: From: Steven Rostedt [EMAIL PROTECTED] Date: Mon, 7 Aug 2006 01:34:56 -0400 (EDT) My suggestion would be to separate that tg3_timer into 4 different timers, which is what it actually looks like

Re: [PATCH -rt DO NOT APPLY] Fix for tg3 networking lockup

On Tue, 8 Aug 2006, David Miller wrote: From: Steven Rostedt [EMAIL PROTECTED] Date: Tue, 8 Aug 2006 08:24:10 -0400 (EDT) Of the 4 timers, only one is a timeout. The other three expire every time, forcing the timer wheel into effect. Even though it's one timer implementing 4, it's

Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() )

On Fri, 19 Jun 2015 13:39:08 -0400 Trond Myklebust trond.mykleb...@primarydata.com wrote: Hang on. This is on the client box while there is an active NFSv4 mount? Then that's probably the NFSv4 callback channel listening for delegation callbacks. Can you please try: echo options nfs

Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() )

of. Is there a way to verify that something can attach to it again? -- Steve Reported-by: Steven Rostedt rost...@goodmis.org Signed-off-by: Trond Myklebust trond.mykleb...@primarydata.com --- net/sunrpc/xprt.c | 2 +- net/sunrpc/xprtsock.c | 8 ++-- 2 files changed, 7 insertions

Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() )

-by: Steven Rostedt rost...@goodmis.org Signed-off-by: Trond Myklebust trond.mykleb...@primarydata.com --- net/sunrpc/xprt.c | 2 +- net/sunrpc/xprtsock.c | 8 ++-- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c index 3ca31f20b97c

Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() )

On Fri, 19 Jun 2015 19:25:59 -0400 Trond Myklebust trond.mykleb...@primarydata.com wrote: On Fri, 2015-06-19 at 18:14 -0400, Steven Rostedt wrote: On Fri, 19 Jun 2015 16:30:18 -0400 Trond Myklebust trond.mykleb...@primarydata.com wrote: Steven, how about something like the following

Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() )

to test RPC traffic resuming? I'd like to try that before declaring this bug harmless. Reported-by: Steven Rostedt rost...@goodmis.org The problem appears to go away with this patch. Tested-by: Steven Rostedt rost...@goodmis.org Thanks a lot! -- Steve Signed-off-by: Trond Myklebust

Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() )

On Fri, 19 Jun 2015 20:37:45 -0400 Steven Rostedt rost...@goodmis.org wrote: Is it causing any other damage than the rkhunter warning you reported? Well, not that I know of. Are you sure that this port will be reconnected, and is not just a leak. Not sure if you could waste more ports

Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() )

On Thu, 18 Jun 2015 18:50:51 -0400 Jeff Layton jlay...@poochiereds.net wrote: The interesting bit here is that the sockets all seem to connect to port 55201 on the remote host, if I'm reading these traces correctly. What's listening on that port on the server? This might give some helpful

Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() )

On Thu, 18 Jun 2015 21:37:02 -0400 Jeff Layton jlay...@poochiereds.net wrote: Note, the box has been rebooted since I posted my last trace. Ahh pity. The port has probably changed...if you trace it again maybe try to figure out what it's talking to before rebooting the server? I could

Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() )

On Thu, 18 Jun 2015 15:24:52 -0400 Trond Myklebust trond.mykleb...@primarydata.com wrote: On Wed, Jun 17, 2015 at 11:08 PM, Steven Rostedt rost...@goodmis.org wrote: On Fri, 12 Jun 2015 11:50:38 -0400 Steven Rostedt rost...@goodmis.org wrote: I reverted the following commits

Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() )

On Fri, 19 Jun 2015 12:25:53 -0400 Steven Rostedt rost...@goodmis.org wrote: I don't see that 55201 anywhere. But then again, I didn't look for it before the port disappeared. I could reboot and look for it again. I should have saved the full netstat -tapn as well :-/ Of course I didn't find

Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() )

On Fri, 12 Jun 2015 11:50:38 -0400 Steven Rostedt rost...@goodmis.org wrote: I reverted the following commits: c627d31ba0696cbd829437af2be2f2dee3546b1e 9e2b9f37760e129cee053cc7b6e7288acc2a7134 caf4ccd4e88cf2795c927834bc488c8321437586 And the issue goes away. That is, I watched the port

Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() )

On Fri, 12 Jun 2015 07:40:35 -0700 Eric Dumazet eric.duma...@gmail.com wrote: Strange, because the usual way to not have time-wait is to use SO_LINGER with linger=0 And apparently xs_tcp_finish_connecting() has this : sock_reset_flag(sk, SOCK_LINGER);

Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() )

On Fri, 12 Jun 2015 11:34:20 -0400 Steven Rostedt rost...@goodmis.org wrote: On Fri, 12 Jun 2015 07:40:35 -0700 Eric Dumazet eric.duma...@gmail.com wrote: Strange, because the usual way to not have time-wait is to use SO_LINGER with linger=0 And apparently xs_tcp_finish_connecting

Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() )

On Fri, 12 Jun 2015 11:50:38 -0400 Steven Rostedt rost...@goodmis.org wrote: On Fri, 12 Jun 2015 11:34:20 -0400 Steven Rostedt rost...@goodmis.org wrote: And the issue goes away. That is, I watched the port go from ESTABLISHED to TIME_WAIT, and then gone, and theirs no hidden port. s

[REGRESSION] NFS is creating a hidden port (left over from xs_bind() )

I recently upgraded my main server to 4.0.4 from 3.19.5 and rkhunter started reporting a hidden port on my box. Running unhide-tcp I see this: # unhide-tcp Unhide-tcp 20121229 Copyright © 2012 Yago Jesus Patrick Gouin License GPLv3+ : GNU GPL version 3 or later

Re: [PATCH] bpf_trace: Make dependent on PERF_EVENTS

On Tue, 10 Nov 2015 15:40:35 -0500 (EST) David Miller wrote: > I'll apply this, thanks Steven et al. Thanks David. -- Steve -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at

[PATCH] bpf_trace: Make dependent on PERF_EVENTS

ne. Link: http://lkml.kernel.org/r/4525348.Aq9YoXkChv@wuerfel Reported-by: Arnd Bergmann <a...@arndb.de> Signed-off-by: Steven Rostedt <rost...@goodmis.org> --- kernel/trace/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/Kconfig b/kerne

Re: [PATCH, REPORT] bpf_trace: build error without PERF_EVENTS

On Tue, 10 Nov 2015 14:31:38 +0100 Daniel Borkmann wrote: > On 11/10/2015 01:55 PM, Arnd Bergmann wrote: > > In my ARM randconfig tests, I'm getting a build error for > > newly added code in bpf_perf_event_read and bpf_perf_event_output > > whenever CONFIG_PERF_EVENTS is

Re: [PATCH] bpf: convert hashtab lock to raw lock

On Mon, 02 Nov 2015 09:12:29 -0800 "Shi, Yang" wrote: > Yes, it is common practice for converting sleepable spin lock to raw > spin lock in -rt to avoid scheduling in atomic context bug. Note, in a lot of cases we don't just convert spin_locks to raw because of atomic

Re: [PATCH] bpf: convert hashtab lock to raw lock

On Fri, 30 Oct 2015 17:03:58 -0700 Alexei Starovoitov wrote: > On Fri, Oct 30, 2015 at 03:16:26PM -0700, Yang Shi wrote: > > When running bpf samples on rt kernel, it reports the below warning: > > > > BUG: sleeping function called from invalid context at > >

Re: Race with ip=dhcp bootparameter in ip_rcv_finish on am335x

On Wed, 23 Sep 2015 14:27:15 +0200 Alexander Aring wrote: \ > Finally I figured out that commit > 4876cc779ff525b9c2376d8076edf47815e71f2c ("SUNRPC: Ensure we release the > TCP socket once it has been closed") occur this races. After reverting > this commit everything works

[FAILED COMPILE v4.3-rc2] conntrack.c:316: undefined reference to `nf_ct_frag6_gather'

The attached config gives the following error: net/built-in.o: In function `handle_fragments': net/openvswitch/conntrack.c:316: undefined reference to `nf_ct_frag6_gather' Makefile:916: recipe for target 'vmlinux' failed -- Steve config.gz Description: application/gzip

Re: [FAILED COMPILE v4.3-rc2] conntrack.c:316: undefined reference to `nf_ct_frag6_gather'

On Tue, 22 Sep 2015 15:16:27 -0700 Joe Stringer <joestrin...@nicira.com> wrote: > On 22 September 2015 at 15:05, Steven Rostedt <rost...@goodmis.org> wrote: > > > > The attached config gives the following error: > > > > net/built-in.o: In function

Re: [PATCH net-next] bpf: add support for %s specifier to bpf_trace_printk()

On Thu, 27 Aug 2015 16:20:39 -0700 (PDT) David Miller da...@davemloft.net wrote: From: Alexei Starovoitov a...@plumgrid.com Date: Thu, 27 Aug 2015 16:06:14 -0700 Fair or you still think it should be per byte copy? I'm terribly surprised we don't have an equivalent of strncpy() for

Re: [PATCH v2 net-next 1/2] lib: introduce strncpy_from_unsafe()

On Fri, 28 Aug 2015 15:08:35 -0700 Alexei Starovoitov a...@plumgrid.com wrote: On 8/28/15 2:48 PM, Steven Rostedt wrote: * On success, returns the length of the string (not including the trailing + * NUL). I think it includes the NUL. oops. yes. that was a copy paste from

Re: [PATCH v2 net-next 1/2] lib: introduce strncpy_from_unsafe()

On Fri, 28 Aug 2015 12:51:48 -0700 Alexei Starovoitov a...@plumgrid.com wrote: EXPORT_SYMBOL(strncpy_from_user); + +/** + * strncpy_from_unsafe: - Copy a NUL terminated string from unsafe address. + * @dst: Destination address, in kernel space. This buffer must be at + * least

Re: [very-RFC 6/8] Add TSN event-tracing

Miller" <da...@davemloft.net> > Cc: Steven Rostedt <rost...@goodmis.org> (maintainer:TRACING) > Cc: Ingo Molnar <mi...@redhat.com> (maintainer:TRACING) > Signed-off-by: Henrik Austad <haus...@cisco.com> > --- > include/trace/events/tsn.h | 349 &g

Re: [very-RFC 6/8] Add TSN event-tracing

On Sun, 12 Jun 2016 23:25:10 +0200 Henrik Austad wrote: > > > +#include > > > +#include > > > +/* #include */ > > > + > > > +/* FIXME: update to TRACE_CLASS to reduce overhead */ > > > > I'm curious to why I didn't do this now. A class would make less > > duplication of

Re: [PATCH][RT] netpoll: Always take poll_lock when doing polling

On Fri, 10 Jun 2016 18:20:22 +0200 Sebastian Andrzej Siewior wrote: > > We actually triggered a starvation due to this. I was just seeing if > > Alison hit the same issue we did in our tests. > > Okay. Didn't get this information from him. But this is only because > the

Re: [PATCH][RT] netpoll: Always take poll_lock when doing polling

On Fri, 10 Jun 2016 17:57:17 +0200 Sebastian Andrzej Siewior <bige...@linutronix.de> wrote: > * Steven Rostedt | 2016-06-04 07:11:31 [-0400]: > > >From: Steven Rostedt <srost...@redhat.com> > >Date: Tue, 5 Jan 2016 14:53:09 -0500 > >Subject: [PATCH] softirq:

Re: [PATCH][RT] netpoll: Always take poll_lock when doing polling

On Thu, 2 Jun 2016 18:12:35 +0200 Sebastian Andrzej Siewior <bige...@linutronix.de> wrote: > * Steven Rostedt | 2016-05-26 19:56:41 [-0400]: > > >[ Alison, can you try this patch ] > > Alison, did you try it? > > Sebastian This patch ma

[PATCH][RT] netpoll: Always take poll_lock when doing polling

y_poll(). Using IS_ENABLED(CONFIG_PREEMPT_RT_FULL) will allow gcc to optimize out the extra calls to poll_lock. Tested-by: "Luis Claudio R. Goncalves" <lgonc...@redhat.com> Reviewed-by: Daniel Bristot de Oliveira <bris...@redhat.com> Signed-off-by: Steven Rostedt <rost...@

It's back! (Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() ))

I've hit this again. Not sure when it started, but I applied my old debug trace_printk() patch (attached) and rebooted (4.5.7). I just tested the latest kernel from Linus's tree (from last nights pull), and it still gives me the problem. Here's the trace I have: kworker/3:1H-134 [003] ..s.

Re: [PATCH net-next 1/8] perf: optimize perf_fetch_caller_regs

On Tue, 5 Apr 2016 14:06:26 +0200 Peter Zijlstra wrote: > On Mon, Apr 04, 2016 at 09:52:47PM -0700, Alexei Starovoitov wrote: > > avoid memset in perf_fetch_caller_regs, since it's the critical path of all > > tracepoints. > > It's called from perf_sw_event_sched,

Re: [PATCH net-next] tuntap: introduce tx skb ring

On Wed, 18 May 2016 18:23:48 +0800 Jason Wang <jasow...@redhat.com> wrote: > > > > > > > Maybe Steven Rostedt have an even better ring queue implementation > > already avail in the kernel? > > > > You mean ring buffer in tracing? Not sure, but it

Re: [PATCH net-next 0/8] allow bpf attach to tracepoints

On Mon, 4 Apr 2016 21:52:46 -0700 Alexei Starovoitov wrote: > Hi Steven, Peter, > > last time we discussed bpf+tracepoints it was a year ago [1] and the reason > we didn't proceed with that approach was that bpf would make arguments > arg1, arg2 to trace_xx(arg1, arg2) call to be

Re: [PATCH net-next 2/8] perf, bpf: allow bpf programs attach to tracepoints

On Mon, 4 Apr 2016 21:52:48 -0700 Alexei Starovoitov wrote: > introduce BPF_PROG_TYPE_TRACEPOINT program type and allow it to be > attached to tracepoints. > The tracepoint will copy the arguments in the per-cpu buffer and pass > it to the bpf program as its first argument. > The

Re: [PATCH net-next 0/8] allow bpf attach to tracepoints

On Mon, 18 Apr 2016 12:51:43 -0700 Alexei Starovoitov wrote: > yeah, it could be added to ftrace as well, but it won't be as effective > as perf_trace, since the cost of trace_event_buffer_reserve() in > trace_event_raw_event_() handler is significantly higher than >

Re: [PATCH net-next] perf, bpf: minimize the size of perf_trace_() tracepoint handler

On Thu, 21 Apr 2016 16:02:55 +0200 Peter Zijlstra <pet...@infradead.org> wrote: > Acked-by: Peter Zijlstra (Intel) <pet...@infradead.org> > > David, please take through the net tree as this depends on prior patches > by Alexei that are already in your tree. Yes p

Re: [PATCH net-next 2/8] perf, bpf: allow bpf programs attach to tracepoints

On Mon, 18 Apr 2016 18:15:04 -0700 Alexei Starovoitov <a...@fb.com> wrote: > On 4/18/16 3:16 PM, Steven Rostedt wrote: > Yes. That what I referred to in below 'a struct to pass args'... > But, fine, will try to optimize the size further. > Frankly much bigger .text savi

Re: [PATCH net-next 2/8] perf, bpf: allow bpf programs attach to tracepoints

On Mon, 18 Apr 2016 14:43:07 -0700 Alexei Starovoitov wrote: > I was worried about this too, but single 'if' and two calls > (as in commit 98b5c2c65c295) is a better way, since it's faster, cleaner > and doesn't need to refactor the whole perf_trace_buf_submit() to pass > extra

Re: [patch net-next 1/2] tracing: change owner name to driver name for devlink hwmsg tracepoint

anox.com> > > Acked-by: Randy Dunlap <rdun...@infradead.org> I may as well add mine too... Acked-by: Steven Rostedt <rost...@goodmis.org> -- Steve

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

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 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: [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: linux-next: Tree for Jul 13 (net/core/devlink with Tracing)

On Wed, 13 Jul 2016 08:12:16 -0700 Randy Dunlap wrote: > On 07/12/16 23:47, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 20160712: > > > > on x86_64: > (full randconfig file is attached) > > > CC net/core/devlink.o > In file included from

Re: [patch net-next 1/2] devlink: add hardware messages tracing facility

On Tue, 12 Jul 2016 10:38:37 +0200 Jiri Pirko wrote: > Hmm, I'm trying to make it work this was but it seems to be a bit more > complicated. I did not find any code doing this (having the tracepoint > compiled in or not) so I cannot copy the solution. > > The problem is that

Re: [patch net-next 1/2] devlink: add hardware messages tracing facility

On Mon, 11 Jul 2016 15:18:47 +0200 Jiri Pirko wrote: > diff --git a/include/net/devlink.h b/include/net/devlink.h > index c99ffe8..865ade6 100644 > --- a/include/net/devlink.h > +++ b/include/net/devlink.h > @@ -115,6 +115,8 @@ struct devlink *devlink_alloc(const struct

Re: [patch net-next v2 1/2] devlink: add hardware messages tracing facility

j...@mellanox.com> > --- > v1->v2: > - Use EXPORT_TRACEPOINT_SYMBOL_GPL instead of a wrapper function > as suggested by David Ahern and Steven Rostedt FYI, you can use the Suggested-by: tag too ;-) > --- > include/trace/events/devlink.h | 68 > +

Re: [patch net-next v2 1/2] devlink: add hardware messages tracing facility

@mellanox.com> > >> > >> Define a tracepoint and allow user to trace messages going to and from > >> hardware associated with devlink instance. > >> > >> Signed-off-by: Jiri Pirko <j...@mellanox.com> > >> --- > >> v1->v2: >

Re: [patch net-next 1/2] devlink: add hardware messages tracing facility

On Mon, 11 Jul 2016 15:18:47 +0200 Jiri Pirko wrote: > From: Jiri Pirko > > Define a tracepoint and allow user to trace messages going to and from > hardware associated with devlink instance. > > Signed-off-by: Jiri Pirko > --- >

It's back! (Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() ))

[ resending as a new email, as I'm assuming people do not sort their INBOX via last email on thread, thus my last email is sitting in the bottom of everyone's INBOX ] I've hit this again. Not sure when it started, but I applied my old debug trace_printk() patch (attached) and rebooted

Re: It's back! (Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() ))

On Thu, 30 Jun 2016 13:17:47 + Trond Myklebust <tron...@primarydata.com> wrote: > > On Jun 30, 2016, at 08:59, Steven Rostedt <rost...@goodmis.org> wrote: > > > > [ resending as a new email, as I'm assuming people do not sort their > > INBOX via last

Re: It's back! (Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() ))

On Thu, 30 Jun 2016 11:23:41 -0400 Steven Rostedt <rost...@goodmis.org> wrote: > I can add more trace_printk()s if it would help. I added a trace_printk() in inet_bind_bucket_destroy() to print out some information on the socket used by xs_bind(), and it shows that the bind destroy

Re: It's back! (Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() ))

On Thu, 30 Jun 2016 18:30:42 + Trond Myklebust wrote: > Wait. So the NFS mount is still active, it’s just that the socket > disconnected due to no traffic? That should be OK. Granted that the > port can’t be reused by another process, but you really don’t want >

Re: It's back! (Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() ))

On Thu, 30 Jun 2016 16:07:26 -0400 Steven Rostedt <rost...@goodmis.org> wrote: > I can reproduce this by having the client unmount and remount the > directory. It gets even more interesting. When I unmount the directory, the hidden port does not go away. It is still there. Bu

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 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 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: [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: [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 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 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 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 >

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 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 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 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 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] 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

[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] 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

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 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] 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 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 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: [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 -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 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: [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

  1   2   >