linux-stable.git/net/tipc/node.c, branch v4.2.4

tipc: add packet sequence number at instant of transmission

2015-05-14T16:24:46+00:00

Currently, the packet sequence number is updated and added to each
packet at the moment a packet is added to the link backlog queue.
This is wasteful, since it forces the code to traverse the send
packet list packet by packet when adding them to the backlog queue.
It would be better to just splice the whole packet list into the
backlog queue when that is the right action to do.

In this commit, we do this change. Also, since the sequence numbers
cannot now be assigned to the packets at the moment they are added
the backlog queue, we do instead calculate and add them at the moment
of transmission, when the backlog queue has to be traversed anyway.
We do this in the function tipc_link_push_packet().

Reviewed-by: Erik Hugne 
Reviewed-by: Ying Xue 
Signed-off-by: Jon Maloy 
Signed-off-by: David S. Miller

tipc: simplify include dependencies

2015-05-14T16:24:45+00:00

When we try to add new inline functions in the code, we sometimes
run into circular include dependencies.

The main problem is that the file core.h, which really should be at
the root of the dependency chain, instead is a leaf. I.e., core.h
includes a number of header files that themselves should be allowed
to include core.h. In reality this is unnecessary, because core.h does
not need to know the full signature of any of the structs it refers to,
only their type declaration.

In this commit, we remove all dependencies from core.h towards any
other tipc header file.

As a consequence of this change, we can now move the function
tipc_own_addr(net) from addr.c to addr.h, and make it inline.

There are no functional changes in this commit.

Reviewed-by: Erik Hugne 
Reviewed-by: Ying Xue 
Signed-off-by: Jon Maloy 
Signed-off-by: David S. Miller

tipc: simplify link mtu negotiation

2015-04-02T20:27:12+00:00

When a link is being established, the two endpoints advertise their
respective interface MTU in the transmitted RESET and ACTIVATE messages.
If there is any difference, the lower of the two MTUs will be selected
for use by both endpoints.

However, as a remnant of earlier attempts to introduce TIPC level
routing. there also exists an MTU discovery mechanism. If an intermediate
node has a lower MTU than the two endpoints, they will discover this
through a bisectional approach, and finally adopt this MTU for common use.

Since there is no TIPC level routing, and probably never will be,
this mechanism doesn't make any sense, and only serves to make the
link level protocol unecessarily complex.

In this commit, we eliminate the MTU discovery algorithm,and fall back
to the simple MTU advertising approach. This change is fully backwards
compatible.

Reviewed-by: Ying Xue 
Signed-off-by: Jon Maloy 
Signed-off-by: David S. Miller

tipc: eliminate delayed link deletion at link failover

2015-04-02T20:27:12+00:00

When a bearer is disabled manually, all its links have to be reset
and deleted. However, if there is a remaining, parallel link ready
to take over a deleted link's traffic, we currently delay the delete
of the removed link until the failover procedure is finished. This
is because the remaining link needs to access state from the reset
link, such as the last received packet number, and any partially
reassembled buffer, in order to perform a successful failover.

In this commit, we do instead move the state data over to the new
link, so that it can fulfill the procedure autonomously, without
accessing any data on the old link. This means that we can now
proceed and delete all pertaining links immediately when a bearer
is disabled. This saves us from some unnecessary complexity in such
situations.

We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
FAILOVER_MSG and SYNCH_MSG respectively.

Reviewed-by: Ying Xue 
Signed-off-by: Jon Maloy 
Signed-off-by: David S. Miller

tipc: involve reference counter for node structure

2015-03-29T19:40:28+00:00

TIPC node hash node table is protected with rcu lock on read side.
tipc_node_find() is used to look for a node object with node address
through iterating the hash node table. As the entire process of what
tipc_node_find() traverses the table is guarded with rcu read lock,
it's safe for us. However, when callers use the node object returned
by tipc_node_find(), there is no rcu read lock applied. Therefore,
this is absolutely unsafe for callers of tipc_node_find().

Now we introduce a reference counter for node structure. Before
tipc_node_find() returns node object to its caller, it first increases
the reference counter. Accordingly, after its caller used it up,
it decreases the counter again. This can prevent a node being used by
one thread from being freed by another thread.

Reviewed-by: Erik Hugne 
Reviewed-by: Jon Maloy 
Signed-off-by: Ying Xue 
Signed-off-by: David S. Miller

tipc: fix potential deadlock when all links are reset

2015-03-29T19:40:27+00:00

[   60.988363] ======================================================
[   60.988754] [ INFO: possible circular locking dependency detected ]
[   60.989152] 3.19.0+ #194 Not tainted
[   60.989377] -------------------------------------------------------
[   60.989781] swapper/3/0 is trying to acquire lock:
[   60.990079]  (&(&n_ptr->lock)->rlock){+.-...}, at: [] tipc_link_retransmit+0x1aa/0x240 [tipc]
[   60.990743]
[   60.990743] but task is already holding lock:
[   60.991106]  (&(&bclink->lock)->rlock){+.-...}, at: [] tipc_bclink_lock+0x8e/0xa0 [tipc]
[   60.991738]
[   60.991738] which lock already depends on the new lock.
[   60.991738]
[   60.992174]
[   60.992174] the existing dependency chain (in reverse order) is:
[   60.992174]
-> #1 (&(&bclink->lock)->rlock){+.-...}:
[   60.992174]        [] lock_acquire+0x9c/0x140
[   60.992174]        [] _raw_spin_lock_bh+0x3f/0x50
[   60.992174]        [] tipc_bclink_lock+0x8e/0xa0 [tipc]
[   60.992174]        [] tipc_bclink_add_node+0x97/0xf0 [tipc]
[   60.992174]        [] tipc_node_link_up+0xf5/0x110 [tipc]
[   60.992174]        [] link_state_event+0x2b3/0x4f0 [tipc]
[   60.992174]        [] tipc_link_proto_rcv+0x24c/0x418 [tipc]
[   60.992174]        [] tipc_rcv+0x827/0xac0 [tipc]
[   60.992174]        [] tipc_l2_rcv_msg+0x73/0xd0 [tipc]
[   60.992174]        [] __netif_receive_skb_core+0x746/0x980
[   60.992174]        [] __netif_receive_skb+0x21/0x70
[   60.992174]        [] netif_receive_skb_internal+0x35/0x130
[   60.992174]        [] napi_gro_receive+0x158/0x1d0
[   60.992174]        [] e1000_clean_rx_irq+0x155/0x490
[   60.992174]        [] e1000_clean+0x267/0x990
[   60.992174]        [] net_rx_action+0x150/0x360
[   60.992174]        [] __do_softirq+0x123/0x360
[   60.992174]        [] irq_exit+0x8e/0xb0
[   60.992174]        [] do_IRQ+0x65/0x110
[   60.992174]        [] ret_from_intr+0x0/0x13
[   60.992174]        [] arch_cpu_idle+0xf/0x20
[   60.992174]        [] cpu_startup_entry+0x2f6/0x3f0
[   60.992174]        [] start_secondary+0x13a/0x150
[   60.992174]
-> #0 (&(&n_ptr->lock)->rlock){+.-...}:
[   60.992174]        [] __lock_acquire+0x163d/0x1ca0
[   60.992174]        [] lock_acquire+0x9c/0x140
[   60.992174]        [] _raw_spin_lock_bh+0x3f/0x50
[   60.992174]        [] tipc_link_retransmit+0x1aa/0x240 [tipc]
[   60.992174]        [] tipc_bclink_rcv+0x611/0x640 [tipc]
[   60.992174]        [] tipc_rcv+0x616/0xac0 [tipc]
[   60.992174]        [] tipc_l2_rcv_msg+0x73/0xd0 [tipc]
[   60.992174]        [] __netif_receive_skb_core+0x746/0x980
[   60.992174]        [] __netif_receive_skb+0x21/0x70
[   60.992174]        [] netif_receive_skb_internal+0x35/0x130
[   60.992174]        [] napi_gro_receive+0x158/0x1d0
[   60.992174]        [] e1000_clean_rx_irq+0x155/0x490
[   60.992174]        [] e1000_clean+0x267/0x990
[   60.992174]        [] net_rx_action+0x150/0x360
[   60.992174]        [] __do_softirq+0x123/0x360
[   60.992174]        [] irq_exit+0x8e/0xb0
[   60.992174]        [] do_IRQ+0x65/0x110
[   60.992174]        [] ret_from_intr+0x0/0x13
[   60.992174]        [] arch_cpu_idle+0xf/0x20
[   60.992174]        [] cpu_startup_entry+0x2f6/0x3f0
[   60.992174]        [] start_secondary+0x13a/0x150
[   60.992174]
[   60.992174] other info that might help us debug this:
[   60.992174]
[   60.992174]  Possible unsafe locking scenario:
[   60.992174]
[   60.992174]        CPU0                    CPU1
[   60.992174]        ----                    ----
[   60.992174]   lock(&(&bclink->lock)->rlock);
[   60.992174]                                lock(&(&n_ptr->lock)->rlock);
[   60.992174]                                lock(&(&bclink->lock)->rlock);
[   60.992174]   lock(&(&n_ptr->lock)->rlock);
[   60.992174]
[   60.992174]  *** DEADLOCK ***
[   60.992174]
[   60.992174] 3 locks held by swapper/3/0:
[   60.992174]  #0:  (rcu_read_lock){......}, at: [] __netif_receive_skb_core+0x71/0x980
[   60.992174]  #1:  (rcu_read_lock){......}, at: [] tipc_l2_rcv_msg+0x5/0xd0 [tipc]
[   60.992174]  #2:  (&(&bclink->lock)->rlock){+.-...}, at: [] tipc_bclink_lock+0x8e/0xa0 [tipc]
[   60.992174]

The correct the sequence of grabbing n_ptr->lock and bclink->lock
should be that the former is first held and the latter is then taken,
which exactly happened on CPU1. But especially when the retransmission
of broadcast link is failed, bclink->lock is first held in
tipc_bclink_rcv(), and n_ptr->lock is taken in link_retransmit_failure()
called by tipc_link_retransmit() subsequently, which is demonstrated on
CPU0. As a result, deadlock occurs.

If the order of holding the two locks happening on CPU0 is reversed, the
deadlock risk will be relieved. Therefore, the node lock taken in
link_retransmit_failure() originally is moved to tipc_bclink_rcv()
so that it's obtained before bclink lock. But the precondition of
the adjustment of node lock is that responding to bclink reset event
must be moved from tipc_bclink_unlock() to tipc_node_unlock().

Reviewed-by: Erik Hugne 
Signed-off-by: Ying Xue 
Signed-off-by: David S. Miller

tipc: split link outqueue

2015-03-14T18:38:32+00:00

struct tipc_link contains one single queue for outgoing packets,
where both transmitted and waiting packets are queued.

This infrastructure is hard to maintain, because we need
to keep a number of fields to keep track of which packets are
sent or unsent, and the number of packets in each category.

A lot of code becomes simpler if we split this queue into a transmission
queue, where sent/unacknowledged packets are kept, and a backlog queue,
where we keep the not yet sent packets.

In this commit we do this separation.

Reviewed-by: Erik Hugne 
Reviewed-by: Ying Xue 
Signed-off-by: Jon Maloy 
Signed-off-by: David S. Miller

tipc: nl compat add noop and remove legacy nl framework

2015-02-09T21:20:49+00:00

Add TIPC_CMD_NOOP to compat layer and remove the old framework.

All legacy nl commands are now converted to the compat layer in
netlink_compat.c.

Signed-off-by: Richard Alpe 
Reviewed-by: Erik Hugne 
Reviewed-by: Ying Xue 
Reviewed-by: Jon Maloy 
Signed-off-by: David S. Miller

tipc: convert legacy nl node dump to nl compat

2015-02-09T21:20:49+00:00

Convert TIPC_CMD_GET_NODES to compat dumpit and remove global node
counter solely used by the legacy API.

Signed-off-by: Richard Alpe 
Reviewed-by: Erik Hugne 
Reviewed-by: Ying Xue 
Reviewed-by: Jon Maloy 
Signed-off-by: David S. Miller

tipc: convert legacy nl link dump to nl compat

2015-02-09T21:20:48+00:00

Convert TIPC_CMD_GET_LINKS to compat dumpit and remove global link
counter solely used by the legacy API.

Signed-off-by: Richard Alpe 
Reviewed-by: Erik Hugne 
Reviewed-by: Ying Xue 
Reviewed-by: Jon Maloy 
Signed-off-by: David S. Miller