From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: davem@davemloft.net
Cc: netdev@vger.kernel.org, allan.stephens@windriver.com,
ying.xue@windriver.com
Subject: [PATCH net-next 12/15] tipc: Prevent loss of fragmented messages over unicast links
Date: Mon, 6 Feb 2012 19:52:45 -0500 [thread overview]
Message-ID: <1328575968-20643-13-git-send-email-paul.gortmaker@windriver.com> (raw)
In-Reply-To: <1328575968-20643-1-git-send-email-paul.gortmaker@windriver.com>
From: Allan Stephens <allan.stephens@windriver.com>
Modifies unicast link endpoint logic so an incoming fragmented message
is not lost if reassembly cannot begin because there is no buffer big
enough to hold the entire reassembled message. The link endpoint now
ignores the first fragment completely, which causes the sending node to
retransmit the first fragment so that reassembly can be re-attempted.
Previously, the sender would have had no reason to retransmit the 1st
fragment, so we would never have a chance to re-try the allocation.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
---
net/tipc/link.c | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index cce9537..d8b0a22 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1774,6 +1774,7 @@ protocol_check:
head = link_insert_deferred_queue(l_ptr,
head);
if (likely(msg_is_dest(msg, tipc_own_addr))) {
+ int ret;
deliver:
if (likely(msg_isdata(msg))) {
tipc_node_unlock(n_ptr);
@@ -1798,11 +1799,15 @@ deliver:
continue;
case MSG_FRAGMENTER:
l_ptr->stats.recv_fragments++;
- if (tipc_link_recv_fragment(&l_ptr->defragm_buf,
- &buf, &msg)) {
+ ret = tipc_link_recv_fragment(
+ &l_ptr->defragm_buf,
+ &buf, &msg);
+ if (ret == 1) {
l_ptr->stats.recv_fragmented++;
goto deliver;
}
+ if (ret == -1)
+ l_ptr->next_in_no--;
break;
case CHANGEOVER_PROTOCOL:
type = msg_type(msg);
@@ -2632,7 +2637,9 @@ int tipc_link_recv_fragment(struct sk_buff **pending, struct sk_buff **fb,
set_fragm_size(pbuf, fragm_sz);
set_expected_frags(pbuf, exp_fragm_cnt - 1);
} else {
- warn("Link unable to reassemble fragmented message\n");
+ dbg("Link unable to reassemble fragmented message\n");
+ buf_discard(fbuf);
+ return -1;
}
buf_discard(fbuf);
return 0;
--
1.7.9
next prev parent reply other threads:[~2012-02-07 0:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-07 0:52 [PATCH net-next 00/15] TIPC updates for upcoming v3.4 Paul Gortmaker
2012-02-07 0:52 ` [PATCH net-next 01/15] tipc: improve the link deferred queue insertion algorithm Paul Gortmaker
2012-02-07 0:52 ` [PATCH net-next 02/15] tipc: Prevent transmission of outdated link protocol messages Paul Gortmaker
2012-02-07 0:52 ` [PATCH net-next 03/15] tipc: Prevent broadcast link stalling in dual LAN environments Paul Gortmaker
2012-02-07 0:52 ` [PATCH net-next 04/15] tipc: Ensure broadcast link re-acquires node after link failure Paul Gortmaker
2012-02-07 0:52 ` [PATCH net-next 05/15] tipc: Fix problem with broadcast link synchronization between nodes Paul Gortmaker
2012-02-07 0:52 ` [PATCH net-next 06/15] tipc: Add missing broadcast link lock when sending NACK Paul Gortmaker
2012-02-07 0:52 ` [PATCH net-next 07/15] tipc: Fix node lock reclamation issues in broadcast link reception Paul Gortmaker
2012-02-07 0:52 ` [PATCH net-next 08/15] tipc: Fix bug in broadcast link duplicate message statistics Paul Gortmaker
2012-02-07 0:52 ` [PATCH net-next 09/15] tipc: Add missing locks in broadcast link statistics accumulation Paul Gortmaker
2012-02-07 0:52 ` [PATCH net-next 10/15] tipc: Major redesign of broadcast link ACK/NACK algorithms Paul Gortmaker
2012-02-07 0:52 ` [PATCH net-next 11/15] tipc: Remove obsolete broadcast tag capability Paul Gortmaker
2012-02-07 0:52 ` Paul Gortmaker [this message]
2012-02-07 0:52 ` [PATCH net-next 13/15] tipc: Prevent loss of fragmented messages over broadcast link Paul Gortmaker
2012-02-07 0:52 ` [PATCH net-next 14/15] tipc: Eliminate alteration of publication key during name table purging Paul Gortmaker
2012-02-07 0:52 ` [PATCH net-next 15/15] tipc: Minor optimization to rejection of connection-based messages Paul Gortmaker
2012-02-07 17:33 ` [PATCH net-next 00/15] TIPC updates for upcoming v3.4 David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1328575968-20643-13-git-send-email-paul.gortmaker@windriver.com \
--to=paul.gortmaker@windriver.com \
--cc=allan.stephens@windriver.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=ying.xue@windriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).