Stephens, Allan | 2 Sep 17:09 2014

Re: maximum links to neighboring mode

Hi Holger:

I'm not really in a good position to answer your question, since I haven't working with TIPC for a couple of
years now. Hopefully there are others on the mailing list who will be able to answer you, such as Jon Maloy or
Erik Hugne. (There are links to their email addresses on the TIPC working group web page at http://tipc.sourceforge.net/working_group.shtml).

Regards,
Al 

> -----Original Message-----
> From: Holger Brunck [mailto:holger.brunck <at> keymile.com]
> Sent: Tuesday, September 02, 2014 11:02 AM
> To: Stephens, Allan
> Cc: tipc-discussion <at> lists.sourceforge.net
> Subject: maximum links to neighboring mode
> 
> Hello Allan,
> currently we migrating some boards to a newer kernel version. In the
> past we used TIPC 1.7.6. Now due to the newer kernel version (3.10) we
> are allowed to use the mainlined TIPC version.
> 
> We have one board which has three different links to a neighboring
> board. With the older TIPC version this was not an issue. But now the
> current TIPC version says that only 2 links are allowed to the other
> board. I saw in the git log that in TIPC 1.6.x only 2 links were allowed
> in TIPC 1.7.6 up to 8 links an in the mainline version they switched
> back to 2 links.
> 
> So my question is. Is recent TIPC able to deal with more then two links
> to a neighboring board or are there good reasons to have the limit of
(Continue reading)

erik.hugne | 1 Sep 09:36 2014
Picon

[PATCH v6 0/5] tipc: add IP/UDP media type

From: Erik Hugne <erik.hugne <at> ericsson.com>

The functionality is fairly isolated, the changes done in the core parts and
userspace API is to allow for longer link names that contains a ':' character.
IPv6 support is not yet possible, as that would violate the current protocol
spec (bearer level originating address field is too small).

Tipcutils (v2.0.6) required to configure UDP bearers.

The intention is to push this to net-next immediately after Richard's
rewrite of the netlink API (Even though they don't conflict).

v6:
   Rebase only

v5:
   This was originally supposed to be a minor edit, but turned out to be quite
   a large chunk of changes, including a new patch that adds the ability to 
   enable several UDP multicast bearers. The bugs fixed are all in Patch #5. 
   With some scripted testing i found and corrected two crashes, aswell as a 
   memory accouting issue that led to a "link-freeze" bug (that actually only 
   happens when this is combined with the new reassembly code, hence the late 
   discovery of the problem). 

 - Orphan skb's received from the udp socket (tipc_udp_recv) before passing them
   to the TIPC stack (memory accounting fix).
 - skb_recv_datagram called from the data_ready callbacks should be nonblocking,
   otherwise we might oops when the the bearer is disabled and socket is 
   released from another context.
 - It is not safe to set the sk_data_ready callbacks to NULL. Correct way seems 
(Continue reading)

Jon Maloy | 28 Aug 20:50 2014
Picon

[PATCH net-next v2 1/1] tipc: fix a potential deadlock

From: Ying Xue <ying.xue <at> windriver.com>

Locking dependency detected below possible unsafe locking scenario:

           CPU0                          CPU1
T0:  tipc_named_rcv()                tipc_rcv()
T1:  [grab nametble write lock]*     [grab node lock]*
T2:  tipc_update_nametbl()           tipc_node_link_up()
T3:  tipc_nodesub_subscribe()        tipc_nametbl_publish()
T4:  [grab node lock]*               [grab nametble write lock]*

The opposite order of holding nametbl write lock and node lock on
above two different paths may result in a deadlock. If we move the
the updating of the name table after link state named out of node
lock, the reverse order of holding locks will be eliminated, and
as a result, the deadlock risk.

v2: Simplified code. Using two new action flags instead of one.
    Added a link_id member to struct tipc_node that contains
    the combination of the links remote and local bearer ids.
    This will make link subscriptions much more useful.

Signed-off-by: Ying Xue <ying.xue <at> windriver.com>
Signed-off-by: Jon Maloy <jon.maloy <at> ericsson.com>
---
 net/tipc/node.c   | 42 ++++++++++++++++++++++++++++++------------
 net/tipc/node.h   |  7 ++++++-
 net/tipc/socket.c |  2 +-
 3 files changed, 37 insertions(+), 14 deletions(-)

(Continue reading)

Ying Xue | 28 Aug 10:42 2014

[PATCH net-next] tipc: fix a potential deadlock

Locking dependency detected below possible unsafe locking scenario:

           CPU0                          CPU1
T0:  tipc_named_rcv()                tipc_rcv()
T1:  [grab nametble write lock]*     [grab node lock]*
T2:  tipc_update_nametbl()           tipc_node_link_up()
T3:  tipc_nodesub_subscribe()        tipc_nametbl_publish()
T4:  [grab node lock]*               [grab nametble write lock]*

The opposite order of holding nametbl write lock and node lock on
above two different paths may result in a deadlock. If we move the
the delivery of link state named messages out of node lock, the
reverse order of holding locks will be eliminated, as a result,
the deadlock will be killed as well.

Signed-off-by: Ying Xue <ying.xue <at> windriver.com>
---
 net/tipc/node.c |   33 +++++++++++++++++++++++++++------
 net/tipc/node.h |    6 +++++-
 2 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/net/tipc/node.c b/net/tipc/node.c
index 17e6378..60a308b 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
 <at>  <at>  -219,11 +219,11  <at>  <at>  void tipc_node_abort_sock_conns(struct list_head *conns)
 void tipc_node_link_up(struct tipc_node *n_ptr, struct tipc_link *l_ptr)
 {
 	struct tipc_link **active = &n_ptr->active_links[0];
-	u32 addr = n_ptr->addr;
(Continue reading)

Jon Maloy | 27 Aug 22:00 2014

Fwd: Re: FW: [RFC PATCH] tipc: add name distributor resiliency queue

I was wondering why I never got any response on this mail.
Now I understand. The only recipient was myself.

Please read and comment.

Regards
///jon

-------- Original Message --------
Subject: 	Re: FW: [RFC PATCH] tipc: add name distributor resiliency queue
Date: 	Mon, 18 Aug 2014 09:53:31 -0400
From: 	Jon Maloy <maloy <at> donjonn.com>
To: 	Jon Maloy <jon.maloy <at> ericsson.com>

On 08/18/2014 09:25 AM, Jon Maloy wrote:
>
> From: Jon Maloy
> Sent: August-15-14 9:31 AM
> To: 'Ying Xue'; Erik Hugne; Richard Alpe
> Cc: tipc-discussion <at> lists.sourceforge.net
> Subject: RE: [RFC PATCH] tipc: add name distributor resiliency queue
>
>
[...]

>
>
> Actually, the correct way to cut through all this is to just permit overlapping
>
> publications. Then there will be no collisions, and no problem to handle.
(Continue reading)

Ying Xue | 27 Aug 09:17 2014

[PATCH] tipc: convert tipc reference table to use generic rhashtable

Now tipc reference table is statically allocated, and its current
size is a bit samll. In addition, heavy tipc users spend a
considerable amount of time in tipc_sk_get() due to the read-lock
on ref_table_lock. Use of relieves the lock contention.

Makes use of the new resizeable hash table to avoid locking on the
lookup.

The hash table will grow if entries exceeds 75% of table size up to a
total table size of 64K. It will automatically shrink if usage falls
below 30%.

Also splits ref_table_lock into a separate mutex to protect hash table
mutations and allow synchronize_rcu() to sleep while waiting for readers
during expansion and shrinking.

Signed-off-by: Ying Xue <ying.xue <at> windriver.com>
---
 net/tipc/Kconfig  |   12 --
 net/tipc/config.c |   24 +--
 net/tipc/core.c   |    8 +-
 net/tipc/core.h   |    1 -
 net/tipc/socket.c |  461 ++++++++++++++++++++---------------------------------
 net/tipc/socket.h |    4 +-
 6 files changed, 182 insertions(+), 328 deletions(-)

diff --git a/net/tipc/Kconfig b/net/tipc/Kconfig
index c890848..91c8a8e 100644
--- a/net/tipc/Kconfig
+++ b/net/tipc/Kconfig
(Continue reading)

Ying Xue | 27 Aug 08:50 2014

[PATCH] tipc: fix a potential oops

When tipc socket instance(tsk) is not got with given reference number
in tipc_sk_get(), tsk is set to NULL. Subsequently we jump to exit
label where to decrease socket reference counter pointed by tsk
pointer in tipc_sk_put(). However, As now tsk is NULL, oops may
happen because of touching a NULL pointer.

Signed-off-by: Ying Xue <ying.xue <at> windriver.com>
---
 net/tipc/socket.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index d416e83..75275c5 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
 <at>  <at>  -2118,9 +2118,9  <at>  <at>  static void tipc_sk_timeout(unsigned long ref)

 	tsk = tipc_sk_get(ref);
 	if (!tsk)
-		goto exit;
-	sk = &tsk->sk;
+		return;

+	sk = &tsk->sk;
 	bh_lock_sock(sk);
 	if (!tsk->connected) {
 		bh_unlock_sock(sk);
--

-- 
1.7.9.5

(Continue reading)

erik.hugne | 26 Aug 11:16 2014
Picon

[PATCH] tipc: add support for link selection overrides

From: Erik Hugne <erik.hugne <at> ericsson.com>

This adds a socket option knob used to alter the link selection
for outgoing messages. This allows applications to override the
default link selection based on port reference and specify if the
primary or secondary link should have precedence.

Signed-off-by: Erik Hugne <erik.hugne <at> ericsson.com>
---
Open question, should we also add the possibility to specify a link
selector per message (as ancillary data)?

 include/uapi/linux/tipc.h |  8 ++++++++
 net/tipc/socket.c         | 28 ++++++++++++++++++++++------
 2 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/include/uapi/linux/tipc.h b/include/uapi/linux/tipc.h
index 6f71b9b..6497fe2 100644
--- a/include/uapi/linux/tipc.h
+++ b/include/uapi/linux/tipc.h
 <at>  <at>  -207,6 +207,14  <at>  <at>  struct sockaddr_tipc {
 #define TIPC_CONN_TIMEOUT	130	/* Default: 8000 (ms)  */
 #define TIPC_NODE_RECVQ_DEPTH	131	/* Default: none (read only) */
 #define TIPC_SOCK_RECVQ_DEPTH	132	/* Default: none (read only) */
+#define TIPC_LINK_SELECTOR	133	/* Default: auto (based on port ref)*/
+
+/*
+ * TIPC link selector values
+ */
+#define TIPC_LINK_AUTO		0xFFFFFFFF
(Continue reading)

Jon Maloy | 23 Aug 00:09 2014
Picon

[PATCH net-next 00/17] tipc: Merge port and socket layer code

After the removal of the TIPC native interface, there is no reason to
keep a distinction between a "generic" port layer and a "specific"
socket layer in the code. Throughout the last months, we have posted
several series that aimed at facilitating removal of the port layer,
and in particular the port_lock spinlock, which in reality duplicates
the role normally kept by lock_sock()/bh_lock_sock().

In this series, we finalize this work, by making a significant number of
changes to the link, node, port and socket code, all with the aim of
reducing dependencies between the layers. In the final commits, we then
remove the port spinlock, port.c and port.h altogether.

After this series, we have a socket layer that has only few dependencies
to the rest of the stack, so that it should be possible to continue
cleanups of its code without significantly affecting other code.

It should be noted that commit ##1 and 2 are already in 'net' 
(ac32c7f705692b92fe12dcbe88fe87136fdfff6f and 
02784f1b05b8f241c8180af88869e717e2758593), but not yet in net-next.
Since they are prerequisites for the rest of the series to apply, I
prepend them to the series.

David S. Miller (1):
  tipc: Fix build.

Erik Hugne (1):
  tipc: fix message importance range check

Jon Maloy (15):
  tipc: introduce new function tipc_msg_create()
(Continue reading)

Jernej Krmelj | 21 Aug 14:29 2014
Picon

Fwd: SO_BINDTODEVICE

Hello,

a short question - does TIPC support SO_BINDTODEVICE socket option? In
order to specify to which interface/bearer to bind a socket. To be able to
send messages over speciffic bearer?

Thanks, Jernej
------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
Ying Xue | 21 Aug 10:18 2014

[PATCH RFC] rps: support tipc

As the sequence control and retransmission of TIPC packets are finished
on link layer, only previous node address and destination node address
contained in TIPC packet header are used to generate skb->rxhash.

However, as TIPC packet header is varied, there exits below special
cases:

- As the previous node address contained in multicast packets may be
  different and destination node address is always 0, 0xffffffff
  and 0 are deemed as source address and destination address of flow
  hash to guarantee all multicast packets can be steered to the same
  core.
- As connection-oriented packet header doesn't include destination
  node address, 0 are supposed as destination address of flow hash.

Signed-off-by: Ying Xue <ying.xue <at> windriver.com>
---
 MAINTAINERS               |    1 +
 include/linux/tipc_msg.h  |   75 +++++++++++++++++++++++++++++++++++++++++++++
 net/core/flow_dissector.c |   26 ++++++++++++++++
 net/tipc/core.h           |    2 +-
 net/tipc/msg.h            |   37 +---------------------
 5 files changed, 104 insertions(+), 37 deletions(-)
 create mode 100644 include/linux/tipc_msg.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 2f85f55..7d39600 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
 <at>  <at>  -9139,6 +9139,7  <at>  <at>  L:	tipc-discussion <at> lists.sourceforge.net (user apps, general discussion)
(Continue reading)


Gmane