Re: net: hang in unregister_netdevice: waiting for lo to become free

2018-02-21 Thread Tommi Rantala
On 20.02.2018 18:26, Neil Horman wrote: On Tue, Feb 20, 2018 at 09:14:41AM +0100, Dmitry Vyukov wrote: On Tue, Feb 20, 2018 at 8:56 AM, Tommi Rantala <tommi.t.rant...@nokia.com> wrote: On 19.02.2018 20:59, Dmitry Vyukov wrote: Is this meant to be fixed already? I am still

Re: net: hang in unregister_netdevice: waiting for lo to become free

2018-02-19 Thread Tommi Rantala
v4 and v6 dst_get, Thanks. Is this meant to be fixed already? I am still seeing this on the latest upstream tree. These two commits are in v4.16-rc1: commit 4a31a6b19f9ddf498c81f5c9b089742b7472a6f8 Author: Tommi Rantala <tommi.t.rant...@nokia.com> Date: Mon Feb 5 21:48:14 2018 +0200

[PATCH net v3] sctp: fix dst refcnt leak in sctp_v4_get_dst

2018-02-05 Thread Tommi Rantala
selection if using secondary addresses") Signed-off-by: Tommi Rantala <tommi.t.rant...@nokia.com> --- v2: unconditional dst_release() before breaking out of the loop: - if dst == NULL, then dst_release() is no-op. - if dst != >dst, then drop reference to the first dst, we do n

[PATCH net v2] sctp: fix dst refcnt leak in sctp_v4_get_dst

2018-02-05 Thread Tommi Rantala
ge count = 1 [ 395.143724] unregister_netdevice: waiting for lo to become free. Usage count = 1 [ 405.383645] unregister_netdevice: waiting for lo to become free. Usage count = 1 ... Fixes: 410f03831 ("sctp: add routing output fallback") Signed-off-by: Tommi Rantala <tommi.t.

Re: [PATCH net] sctp: fix dst reference leak in sctp_v4_get_dst

2018-02-05 Thread Tommi Rantala
On 05.02.2018 03:01, Marcelo Ricardo Leitner wrote: Hi, On Sun, Feb 04, 2018 at 11:02:39AM +0200, Tommi Rantala wrote: Fix dst reference leak in sctp_v4_get_dst() introduced in commit 410f03831 ("sctp: add routing output fallback"): When walking the address_list,

[PATCH net] sctp: fix dst reference leak in sctp_v4_get_dst

2018-02-04 Thread Tommi Rantala
; Cc: Marcelo Ricardo Leitner <marcelo.leit...@gmail.com> Cc: Alexey Kodanev <alexey.koda...@oracle.com> Signed-off-by: Tommi Rantala <tommi.t.rant...@nokia.com> --- net/sctp/protocol.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/net/sctp/protocol.c b/net/s

Re: sctp netns "unregister_netdevice: waiting for lo to become free. Usage count = 1"

2018-02-04 Thread Tommi Rantala
On 02.02.2018 14:34, Neil Horman wrote: Patch looks good, but if you could please submit it with the proper title in a separate thread so it gets davem's attention properly, I'd appreciate it. Additional points if you update it to include the ipv6 fixes :) Thanks, I'll send this patch

Re: sctp netns "unregister_netdevice: waiting for lo to become free. Usage count = 1"

2018-02-02 Thread Tommi Rantala
2018-02-02 1:57 GMT+02:00 Alexey Kodanev : > For ipv6 part, shouldn't we release 'bdst' there if the previous address > match is better and we continue to the next iteration? Good catch! Didn't see that one. Tommi > diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c >

Re: sctp netns "unregister_netdevice: waiting for lo to become free. Usage count = 1"

2018-02-01 Thread Tommi Rantala
inux-sctp/msg07005.html >From b94c037d27e36a3053e6862b7e7da5f07f2f5597 Mon Sep 17 00:00:00 2001 From: Tommi Rantala <tommi.t.rant...@nokia.com> Date: Wed, 31 Jan 2018 11:24:31 + Subject: [PATCH] sctp: fix dst leak in sctp_v4_get_dst Fix dst reference leak in sctp_v4_get_dst() introduced i

Re: sctp netns "unregister_netdevice: waiting for lo to become free. Usage count = 1"

2018-02-01 Thread Tommi Rantala
2018-01-31 19:51 GMT+02:00 Tommi Rantala <tommi.t.rant...@nokia.com>: > On 31.01.2018 14:31, Neil Horman wrote: >> >> On Wed, Jan 31, 2018 at 11:42:24AM +0200, Tommi Rantala wrote: >>> >>> I think there's a problem in the dst refcounting in sctp_v4_get_d

Re: sctp netns "unregister_netdevice: waiting for lo to become free. Usage count = 1"

2018-01-31 Thread Tommi Rantala
On 31.01.2018 14:31, Neil Horman wrote: On Wed, Jan 31, 2018 at 11:42:24AM +0200, Tommi Rantala wrote: I think there's a problem in the dst refcounting in sctp_v4_get_dst() There's a dst_entry struct that has >0 refcnt after running the testcase, which makes it impossible to del

Re: sctp netns "unregister_netdevice: waiting for lo to become free. Usage count = 1"

2018-01-31 Thread Tommi Rantala
On 31.01.2018 11:42, Tommi Rantala wrote: I think there's a problem in the dst refcounting in sctp_v4_get_dst() There's a dst_entry struct that has >0 refcnt after running the testcase, which makes it impossible to delete the loopback device, as that dst is never freed. I'll try to m

Re: sctp netns "unregister_netdevice: waiting for lo to become free. Usage count = 1"

2018-01-31 Thread Tommi Rantala
On 30.01.2018 23:03, Neil Horman wrote: On Tue, Jan 30, 2018 at 09:24:17PM +0200, Tommi Rantala wrote: On 30.01.2018 17:59, Neil Horman wrote: On Mon, Jan 29, 2018 at 05:55:45PM +0200, Tommi Rantala wrote: ip netns add TEST ip netns exec TEST ip link set lo up ip link add dummy0 type dummy

Re: sctp netns "unregister_netdevice: waiting for lo to become free. Usage count = 1"

2018-01-30 Thread Tommi Rantala
On 31.01.2018 00:52, Marcelo Ricardo Leitner wrote: On Mon, Jan 29, 2018 at 05:55:45PM +0200, Tommi Rantala wrote: Hi, When running sctp_test from lksctp-tools in netns in 4.4 and 4.9 with suitable arguments, the local loopback device in the netns is not getting destroyed after deleting

Re: sctp netns "unregister_netdevice: waiting for lo to become free. Usage count = 1"

2018-01-30 Thread Tommi Rantala
On 30.01.2018 17:59, Neil Horman wrote: On Mon, Jan 29, 2018 at 05:55:45PM +0200, Tommi Rantala wrote: ip netns add TEST ip netns exec TEST ip link set lo up ip link add dummy0 type dummy ip link add dummy1 type dummy ip link add dummy2 type dummy ip link set dev dummy0 netns TEST ip link set

sctp netns "unregister_netdevice: waiting for lo to become free. Usage count = 1"

2018-01-29 Thread Tommi Rantala
Hi, When running sctp_test from lksctp-tools in netns in 4.4 and 4.9 with suitable arguments, the local loopback device in the netns is not getting destroyed after deleting the netns. For example: ip netns add TEST ip netns exec TEST ip link set lo up ip link add dummy0 type dummy ip link

[PATCH net 2/2] tipc: fix tipc_mon_delete() oops in tipc_enable_bearer() error path

2017-12-21 Thread Tommi Rantala
] ---[ end trace e811818d54d5ce88 ]--- Acked-by: Ying Xue <ying@windriver.com> Acked-by: Jon Maloy <jon.ma...@ericsson.com> Signed-off-by: Tommi Rantala <tommi.t.rant...@nokia.com> --- net/tipc/monitor.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/ne

[PATCH net 1/2] tipc: error path leak fixes in tipc_enable_bearer()

2017-12-21 Thread Tommi Rantala
Fix memory leak in tipc_enable_bearer() if enable_media() fails, and cleanup with bearer_disable() if tipc_mon_create() fails. Acked-by: Ying Xue <ying@windriver.com> Acked-by: Jon Maloy <jon.ma...@ericsson.com> Signed-off-by: Tommi Rantala <tommi.t.rant...@nokia.com> ---

Re: [PATCH net v2] tipc: call tipc_rcv() only if bearer is up in tipc_udp_recv()

2017-12-01 Thread Tommi Rantala
On 01.12.2017 15:18, Ying Xue wrote: On 11/30/2017 08:32 PM, Tommi Rantala wrote: In my opinion, the real root cause of the issue is because we too early set a not-yet-initialized bearer instance to ub->bearer through rcu_assign_pointer(ub->bearer, b) in tipc_udp_enable(). Instead if we

Re: [PATCH net v2] tipc: call tipc_rcv() only if bearer is up in tipc_udp_recv()

2017-11-30 Thread Tommi Rantala
On 30.11.2017 12:57, Ying Xue wrote: On 11/29/2017 06:48 PM, Tommi Rantala wrote: Remove the second tipc_rcv() call in tipc_udp_recv(). We have just checked that the bearer is not up, and calling tipc_rcv() with a bearer that is not up leads to a TIPC div-by-zero crash

[PATCH net v2] tipc: call tipc_rcv() only if bearer is up in tipc_udp_recv()

2017-11-29 Thread Tommi Rantala
. Fixes: c9b64d492b1f ("tipc: add replicast peer discovery") Signed-off-by: Tommi Rantala <tommi.t.rant...@nokia.com> Cc: Jon Maloy <jon.ma...@ericsson.com> --- v2: Resorted to a minimal fix, as per feedback from David M. net/tipc/udp_media.c | 4 1 file changed, 4 del

Re: [PATCH] tipc: call tipc_rcv() only if bearer is up in tipc_udp_recv()

2017-11-28 Thread Tommi Rantala
On 28.11.2017 16:58, David Miller wrote: From: Tommi Rantala <tommi.t.rant...@nokia.com> Date: Tue, 28 Nov 2017 14:53:15 +0200 - - if (unlikely(msg_user(hdr) == LINK_CONFIG)) { - err = tipc_udp_rcast_disc(b, skb); - if (err) -

[PATCH] tipc: call tipc_rcv() only if bearer is up in tipc_udp_recv()

2017-11-28 Thread Tommi Rantala
8200 (relocation range: 0x8000-0xbfff) [ 12.751215] Rebooting in 60 seconds.. Fixes: c9b64d492b1f ("tipc: add replicast peer discovery") Signed-off-by: Tommi Rantala <tommi.t.rant...@nokia.com> --- net/tipc/udp_media.c | 29 +++--

tipc_node_calculate_timer div-by-zero

2017-11-27 Thread Tommi Rantala
Hi, I'm seeing a rare TIPC div-by-zero crash in tipc_node_calculate_timer(). If I get it right, we're receiving a discovery packet while enabling a bearer. The bearer is not yet fully initialized, causing the discovery packet processing to use zero tolerance value, which then causes the

Re: tipc_udp_send_msg oops in 4.4 when setting link tolerance

2017-11-15 Thread Tommi Rantala
On 14.11.2017 13:35, Jon Maloy wrote: Found it, the missing patch is this one (9b3009604b8e does not help): commit d01332f1acacc0cb43a61f4244dd2b846d4cd585 Author: Richard Alpe Date: Mon Feb 1 08:19:56 2016 +0100 tipc: fix link attribute propagation bug It

Re: tipc_udp_send_msg oops in 4.4 when setting link tolerance

2017-11-14 Thread Tommi Rantala
cc0cb43a61f4244dd2b846d4cd585 upstream. [backported to 4.4 by Tommi Rantala] Changing certain link attributes (link tolerance and link priority) from the TIPC management tool is supposed to automatically take effect at both endpoints of the affected link. Currently the media address is not insta

tipc_udp_send_msg oops in 4.4 when setting link tolerance

2017-11-13 Thread Tommi Rantala
Hi, I always get an instant TIPC oops in 4.4, when I try to set the link tolerance (with LINKNAME != "broadcast-link"): $ tipc link set tolerance 1000 link $LINKNAME Any idea what's going on? Some tipc patch missing in 4.4? In 4.9 the "tipc" command executes just fine, but I've seen a few

Re: "tipc: fix socket timer deadlock" to stable?

2017-03-21 Thread Tommi Rantala
On 13.03.2017 14:18, Jon Maloy wrote: -Original Message- From: Tommi Rantala [mailto:tommi.t.rant...@nokia.com] We're seeing this tipc deadlock in 4.4.y, that was fixed in the mainline commit f1d048f24e66ba85d3dabf3d076cefa5f2b546b0 "tipc: fix socket timer deadlock". Co

"tipc: fix socket timer deadlock" to stable?

2017-03-13 Thread Tommi Rantala
Hello, We're seeing this tipc deadlock in 4.4.y, that was fixed in the mainline commit f1d048f24e66ba85d3dabf3d076cefa5f2b546b0 "tipc: fix socket timer deadlock". Could/should this patch also be included in the stable kernel trees? I just checked that the patch applies on top of 4.4.53,