Richard Alpe | 27 Jun 13:34 2016
Picon

[PATCH net-next 1/2] tipc: honor msg2addr return value

The UDP msg2addr function tipc_udp_msg2addr() can return -EINVAL which
prior to this patch was unhanded in the caller.

Signed-off-by: Richard Alpe <richard.alpe <at> ericsson.com>
Acked-by: Jon Maloy <jon.maloy <at> ericsson.com>
Acked-by: Ying Xue <ying.xue <at> windriver.com>
---
 net/tipc/discover.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/tipc/discover.c b/net/tipc/discover.c
index ad9d477..6b109a8 100644
--- a/net/tipc/discover.c
+++ b/net/tipc/discover.c
 <at>  <at>  -135,9 +135,12  <at>  <at>  void tipc_disc_rcv(struct net *net, struct sk_buff *skb,
 	u16 caps = msg_node_capabilities(hdr);
 	bool respond = false;
 	bool dupl_addr = false;
+	int err;

-	bearer->media->msg2addr(bearer, &maddr, msg_media_addr(hdr));
+	err = bearer->media->msg2addr(bearer, &maddr, msg_media_addr(hdr));
 	kfree_skb(skb);
+	if (err)
+		return;

 	/* Ensure message from node is valid and communication is permitted */
 	if (net_id != tn->net_id)
--

-- 
2.1.4
(Continue reading)

Richard Alpe | 22 Jun 10:03 2016
Picon

[PATCH net-next 0/3] tipc: minor UDP fixes and refactoring

Did some minor UDP refactoring in the midst of some UDP features I'm
working on. Sending them in a separate patchset as they should make
sense even without the rest of the changes I'm wokring on.

Richard Alpe (3):
  tipc: honor msg2addr return value
  tipc: rename udp_port in struct udp_media_addr
  tipc: use sock addr family to indicate IP version

 net/tipc/discover.c  |  5 ++++-
 net/tipc/udp_media.c | 50 +++++++++++++++++++++++++-------------------------
 2 files changed, 29 insertions(+), 26 deletions(-)

--

-- 
2.1.4

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
Jon Maloy | 20 Jun 15:20 2016
Picon

[PATCH net 1/1] tipc: unclone unbundled buffers before forwarding

When extracting an individual message from a received "bundle" buffer,
we just create a clone of the base buffer, and adjust it to point into
the right position of the linearized data area of the latter. This works
well for regular message reception, but during periods of extremely high
load it may happen that an extracted buffer, e.g, a connection probe, is
reversed and forwarded through an external interface while the preceding
extracted message is still unhandled. When this happens, the header or
data area of the preceding message will be partially overwritten by a
MAC header, leading to unpredicatable consequences, such as a link
reset.

We now fix this by ensuring that the msg_reverse() function never
returns a cloned buffer, and that the returned buffer always contains
sufficient valid head and tail room to be forwarded.

Reported-by: Erik Hugne <erik.hugne <at> gmail.com>
Acked-by: Ying Xue <ying.xue <at> windriver.com>
Signed-off-by: Jon Maloy <jon.maloy <at> ericsson.com>
---
 net/tipc/msg.c |  6 ++++++
 net/tipc/msg.h | 11 -----------
 2 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/net/tipc/msg.c b/net/tipc/msg.c
index 8740930..17201aa 100644
--- a/net/tipc/msg.c
+++ b/net/tipc/msg.c
 <at>  <at>  -41,6 +41,8  <at>  <at> 
 #include "name_table.h"

(Continue reading)

Jon Maloy | 18 Jun 22:38 2016
Picon

[PATCH net v2 1/1] tipc: unclone unbundled buffers before forwarding

When extracting an individual message from a received "bundle" buffer,
we just create a clone of the base buffer, and adjust it to point into
the right position of the linearized data area of the latter. This works
well for regular message reception, but during periods of extremely high
load it may happen that an extracted buffer, e.g, a connection probe, is
reversed and forwarded through an external interface while the preceding
extracted message is still unhandled. When this happens, the header or
data area of the preceding message will be partially overwritten by a
MAC header, leading to unpredicatable consequences, such as a link
reset.

We now fix this by ensuring that the msg_reverse() function never
returns a cloned buffer, and that the returned buffer always contains
sufficient valid head and tail room to be forwarded.

v2: Finally figured out why pskb_expand_head() didn't seem to solve the
    problem at my first attempt. When I removed my own debug
    instrumentation  everything worked fine.

Reported-by: Erik Hugne <erik.hugne <at> gmail.com>
Signed-off-by: Jon Maloy <jon.maloy <at> ericsson.com>
---
 net/tipc/msg.c |  6 ++++++
 net/tipc/msg.h | 11 -----------
 2 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/net/tipc/msg.c b/net/tipc/msg.c
index 8740930..17201aa 100644
--- a/net/tipc/msg.c
+++ b/net/tipc/msg.c
(Continue reading)

Jon Maloy | 17 Jun 12:35 2016
Picon

[PATCH net 1/1] tipc: fix socket timer deadlock

We sometimes observe a 'deadly embrace' type deadlock occurring
between mutually connected sockets on the same node. This happens
when the one-hour peer supervision timers happen to expire
simultaneously in both sockets.

The scenario is as follows:

CPU 1:                          CPU 2:
--------                        --------
tipc_sk_timeout(sk1)            tipc_sk_timeout(sk2)
  lock(sk1.slock)                 lock(sk2.slock)
  msg_create(probe)               msg_create(probe)
  unlock(sk1.slock)               unlock(sk2.slock)
  tipc_node_xmit_skb()            tipc_node_xmit_skb()
    tipc_node_xmit()                tipc_node_xmit()
      tipc_sk_rcv(sk2)                tipc_sk_rcv(sk1)
        lock(sk2.slock)                 lock((sk1.slock)
        filter_rcv()                    filter_rcv()
          tipc_sk_proto_rcv()             tipc_sk_proto_rcv()
            msg_create(probe_rsp)           msg_create(probe_rsp)
            tipc_sk_respond()               tipc_sk_respond()
              tipc_node_xmit_skb()            tipc_node_xmit_skb()
                tipc_node_xmit()                tipc_node_xmit()
                  tipc_sk_rcv(sk1)                tipc_sk_rcv(sk2)
                    lock((sk1.slock)                lock((sk2.slock)
                    ===> DEADLOCK                   ===> DEADLOCK

Further analysis reveals that there are three different locations in the
socket code where tipc_sk_respond() is called within the context of the
socket lock, with ensuing risk of similar deadlocks.
(Continue reading)

Jon Maloy | 16 Jun 17:10 2016
Picon

[PATCH net-next 1/1] tipc: unclone unbundled buffers before forwarding

When extracting an individual message from a received "bundle" buffer,
we just create a clone of the base buffer, and adjust it to point into
the right position of the linearized data area of the latter. This works
well for regular message reception, but during periods of extremely high
load it may happen that an extracted buffer, e.g, a connection probe, is
reversed and forwarded through an external interface while the preceding
extracted message is still unhandled. When this happens, the header or
data area of the preceding message will be partially overwritten by a
MAC header, leading to unpredicatable consequences, such as a link
reset.

We now fix this by ensuring that the msg_reverse() function never
returns a cloned buffer, and that the returned buffer always contains
sufficient valid head and tail room to be forwarded.

Reported-by: Erik Hugne <erik.hugne <at> gmail.com>
Signed-off-by: Jon Maloy <jon.maloy <at> ericsson.com>
---
 net/tipc/msg.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/net/tipc/msg.c b/net/tipc/msg.c
index 8740930..00b4f26 100644
--- a/net/tipc/msg.c
+++ b/net/tipc/msg.c
 <at>  <at>  -492,7 +492,7  <at>  <at>  bool tipc_msg_reverse(u32 own_node,  struct sk_buff **skb, int err)
 	/* Take a copy of original header before altering message */
 	memcpy(&ohdr, hdr, msg_hdr_sz(hdr));

-	/* Never return SHORT header; expand by replacing buffer if necessary */
(Continue reading)

Jon Maloy | 15 Jun 16:45 2016
Picon

[PATCH net v5 1/1] tipc: fix socket timer deadlock

We sometimes observe a 'deadly embrace' type deadlock occurring
between mutually connected sockets on the same node. This happens
when the one-hour peer supervision timers happen to expire
simultaneously in both sockets.

The scenario is as follows:

CPU 1:                          CPU 2:
--------                        --------
tipc_sk_timeout(sk1)            tipc_sk_timeout(sk2)
  lock(sk1.slock)                 lock(sk2.slock)
  msg_create(probe)               msg_create(probe)
  unlock(sk1.slock)               unlock(sk2.slock)
  tipc_node_xmit_skb()            tipc_node_xmit_skb()
    tipc_node_xmit()                tipc_node_xmit()
      tipc_sk_rcv(sk2)                tipc_sk_rcv(sk1)
        lock(sk2.slock)                 lock((sk1.slock)
        filter_rcv()                    filter_rcv()
          tipc_sk_proto_rcv()             tipc_sk_proto_rcv()
            msg_create(probe_rsp)           msg_create(probe_rsp)
            tipc_sk_respond()               tipc_sk_respond()
              tipc_node_xmit_skb()            tipc_node_xmit_skb()
                tipc_node_xmit()                tipc_node_xmit()
                  tipc_sk_rcv(sk1)                tipc_sk_rcv(sk2)
                    lock((sk1.slock)                lock((sk2.slock)
                    ===> DEADLOCK                   ===> DEADLOCK

Further analysis reveals that there are at least three different
locations in the socket code where tipc_sk_respond() is called within
the context of the socket lock, with ensuing risk of similar deadlocks.
(Continue reading)

Jon Maloy | 14 Jun 14:35 2016
Picon

[PATCH net v4 1/1] tipc: fix socket timer deadlock

We sometimes observe a 'deadly embrace' type deadlock occurring
between mutually connected sockets on the same node. This happens
when the one-hour peer supervision timers happen to expire
simultaneously in both sockets.

The scenario is as follows:

CPU 1:                          CPU 2:
--------                        --------
tipc_sk_timeout(sk1)            tipc_sk_timeout(sk2)
  lock(sk1.slock)                 lock(sk2.slock)
  msg_create(probe)               msg_create(probe)
  unlock(sk1.slock)               unlock(sk2.slock)
  tipc_node_xmit_skb()            tipc_node_xmit_skb()
    tipc_node_xmit()                tipc_node_xmit()
      tipc_sk_rcv(sk2)                tipc_sk_rcv(sk1)
        lock(sk2.slock)                 lock((sk1.slock)
        filter_rcv()                    filter_rcv()
          tipc_sk_proto_rcv()             tipc_sk_proto_rcv()
            msg_create(probe_rsp)           msg_create(probe_rsp)
            tipc_sk_respond()               tipc_sk_respond()
              tipc_node_xmit_skb()            tipc_node_xmit_skb()
                tipc_node_xmit()                tipc_node_xmit()
                  tipc_sk_rcv(sk1)                tipc_sk_rcv(sk2)
                    lock((sk1.slock)                lock((sk2.slock)
                    ===> DEADLOCK                   ===> DEADLOCK

Further analysis reveals that there are at least three different
locations in the socket code where tipc_sk_respond() is called within
the context of the socket lock, with ensuing risk of similar deadlocks.
(Continue reading)

Jon Maloy | 13 Jun 19:51 2016
Picon

[PATCH net v3 1/1] tipc: fix socket timer deadlock

We sometimes observe a 'deadly embrace' type deadlock occurring
between mutually connected sockets on the same node. This happens
when the one-hour peer supervision timers happen to expire
simultaneously in both sockets.

The scenario is as follows:

CPU 1:                          CPU 2:
--------                        --------
tipc_sk_timeout(sk1)            tipc_sk_timeout(sk2)
  lock(sk1.slock)                 lock(sk2.slock)
  msg_create(probe)               msg_create(probe)
  unlock(sk1.slock)               unlock(sk2.slock)
  tipc_node_xmit_skb()            tipc_node_xmit_skb()
    tipc_node_xmit()                tipc_node_xmit()
      tipc_sk_rcv(sk2)                tipc_sk_rcv(sk1)
        lock(sk2.slock)                 lock((sk1.slock)
        filter_rcv()                    filter_rcv()
          tipc_sk_proto_rcv()             tipc_sk_proto_rcv()
            msg_create(probe_rsp)           msg_create(probe_rsp)
            tipc_sk_respond()               tipc_sk_respond()
              tipc_node_xmit_skb()            tipc_node_xmit_skb()
                tipc_node_xmit()                tipc_node_xmit()
                  tipc_sk_rcv(sk1)                tipc_sk_rcv(sk2)
                    lock((sk1.slock)                lock((sk2.slock)
                    ===> DEADLOCK                   ===> DEADLOCK

Further analysis reveals that there are at least three different
locations in the socket code where tipc_sk_respond() is called within
the context of the socket lock, with ensuing risk of similar deadlocks.
(Continue reading)

GUNA | 13 Jun 17:45 2016
Picon

tipc: fix socket timer deadlock

Hi Jon,

Please let me know where I could get the patch for this fix.

Thanks,
Guna

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
Arjun Pandey | 13 Jun 07:35 2016
Picon

Configuring multiple network ids on a node

Hi all

I was trying to just bring up a basic tipc network.  I had a doubt
about the following text from the programmer's guide
"A TIPC network is also assigned a network identifier. This allows
multiple logical networks to use the same physical medium (for
example, the same Ethernet LAN cables) without interfering with one
another, since each node in the only recognizes traffic originating
from nodes having the same network identifier it has been assigned to
use."
Based on my understanding of the above we should be able to configure
multiple netid's on the same eth port. This effictively would allow
one to have 2 TIPC networks via the same port.

However if i try to do that i get the following error
[root <at> ucc1 tipc-config]# ./tipc-config  -netid
current network id: 4711
[root <at> ucc1 tipc-config]# ./tipc-config  -netid=1231

operation not supported (cannot change network id once TIPC has joined
a network)

I tried multiple options of trying it out.

In my setup , i enabled tipc in make menuconfig options and then
compiled the kernel(3.15.2).
This is running on CentOS6.5. I have downloaded latest avaiable
tipc-utils from the tipc homepage.

Any pointers would be helpful.
(Continue reading)


Gmane