summaryrefslogtreecommitdiff
path: root/net/tipc
diff options
context:
space:
mode:
authorErik Hugne <erik.hugne@ericsson.com>2013-11-06 09:28:07 +0100
committerDavid S. Miller <davem@davemloft.net>2013-11-07 18:30:11 -0500
commita715b49e79b0924863ff1424f9823cc1b5972322 (patch)
tree01dd481f7f1aca3d2151abc31b14a2d92ed3a7b8 /net/tipc
parent40ba3cdf542a469aaa9083fa041656e59b109b90 (diff)
tipc: reassembly failures should cause link reset
If appending a received fragment to the pending fragment chain in a unicast link fails, the current code tries to force a retransmission of the fragment by decrementing the 'next received sequence number' field in the link. This is done under the assumption that the failure is caused by an out-of-memory situation, an assumption that does not hold true after the previous patch in this series. A failure to append a fragment can now only be caused by a protocol violation by the sending peer, and it must hence be assumed that it is either malicious or buggy. Either way, the correct behavior is now to reset the link instead of trying to revert its sequence number. So, this is what we do in this commit. Signed-off-by: Erik Hugne <erik.hugne@ericsson.com> Reviewed-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/tipc')
-rw-r--r--net/tipc/link.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/net/tipc/link.c b/net/tipc/link.c
index a63646e6c2cf..cf465d66ccde 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1652,7 +1652,7 @@ deliver:
goto deliver;
}
if (ret == LINK_REASM_ERROR)
- l_ptr->next_in_no--;
+ tipc_link_reset(l_ptr);
tipc_node_unlock(n_ptr);
continue;
case CHANGEOVER_PROTOCOL: