From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: davem@davemloft.net
Cc: netdev@vger.kernel.org, allan.stephens@windriver.com,
ying.xue@windriver.com,
Paul Gortmaker <paul.gortmaker@windriver.com>
Subject: [PATCH net-next 07/15] tipc: Fix node lock reclamation issues in broadcast link reception
Date: Mon, 6 Feb 2012 19:52:40 -0500 [thread overview]
Message-ID: <1328575968-20643-8-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>
Fixes a pair of problems in broadcast link message reception code
relating to the reclamation of the node lock after consuming an
in-sequence message.
1) Now retests to see if the sending node is still up after reclaiming
the node lock, and bails out if it is non-operational.
2) Now manipulates the node's deferred message queue only after
reclaiming the node lock, rather than using queue head pointer
information that was cached previously.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/tipc/bcast.c | 58 +++++++++++++++++++++++++++++++++++++----------------
1 files changed, 40 insertions(+), 18 deletions(-)
diff --git a/net/tipc/bcast.c b/net/tipc/bcast.c
index 7342abc..e7df313 100644
--- a/net/tipc/bcast.c
+++ b/net/tipc/bcast.c
@@ -474,7 +474,7 @@ void tipc_bclink_recv_pkt(struct sk_buff *buf)
struct tipc_node *node;
u32 next_in;
u32 seqno;
- struct sk_buff *deferred;
+ int deferred;
/* Screen out unwanted broadcast messages */
@@ -489,6 +489,8 @@ void tipc_bclink_recv_pkt(struct sk_buff *buf)
if (unlikely(!node->bclink.supported))
goto unlock;
+ /* Handle broadcast protocol message */
+
if (unlikely(msg_user(msg) == BCAST_PROTOCOL)) {
if (msg_type(msg) != STATE_MSG)
goto unlock;
@@ -513,11 +515,11 @@ void tipc_bclink_recv_pkt(struct sk_buff *buf)
/* Handle in-sequence broadcast message */
-receive:
- next_in = mod(node->bclink.last_in + 1);
seqno = msg_seqno(msg);
+ next_in = mod(node->bclink.last_in + 1);
if (likely(seqno == next_in)) {
+receive:
bcl->stats.recv_info++;
node->bclink.last_in++;
bclink_set_gap(node);
@@ -551,23 +553,40 @@ receive:
buf_discard(buf);
}
buf = NULL;
+
+ /* Determine new synchronization state */
+
tipc_node_lock(node);
- deferred = node->bclink.deferred_head;
- if (deferred && (buf_seqno(deferred) == mod(next_in + 1))) {
- buf = deferred;
- msg = buf_msg(buf);
- node->bclink.deferred_head = deferred->next;
- goto receive;
- }
- } else if (less(next_in, seqno)) {
+ if (unlikely(!tipc_node_is_up(node)))
+ goto unlock;
+
+ if (!node->bclink.deferred_head)
+ goto unlock;
+
+ msg = buf_msg(node->bclink.deferred_head);
+ seqno = msg_seqno(msg);
+ next_in = mod(next_in + 1);
+ if (seqno != next_in)
+ goto unlock;
+
+ /* Take in-sequence message from deferred queue & deliver it */
+
+ buf = node->bclink.deferred_head;
+ node->bclink.deferred_head = buf->next;
+ goto receive;
+ }
+
+ /* Handle out-of-sequence broadcast message */
+
+ if (less(next_in, seqno)) {
u32 gap_after = node->bclink.gap_after;
u32 gap_to = node->bclink.gap_to;
- if (tipc_link_defer_pkt(&node->bclink.deferred_head,
- &node->bclink.deferred_tail,
- buf)) {
+ deferred = tipc_link_defer_pkt(&node->bclink.deferred_head,
+ &node->bclink.deferred_tail,
+ buf);
+ if (deferred) {
node->bclink.nack_sync++;
- bcl->stats.deferred_recv++;
if (seqno == mod(gap_after + 1))
node->bclink.gap_after = seqno;
else if (less(gap_after, seqno) && less(seqno, gap_to))
@@ -579,9 +598,12 @@ receive:
bclink_send_nack(node);
bclink_set_gap(node);
}
- } else {
- bcl->stats.duplicates++;
- }
+ } else
+ deferred = 0;
+
+ if (deferred)
+ bcl->stats.deferred_recv++;
+
unlock:
tipc_node_unlock(node);
exit:
--
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 ` Paul Gortmaker [this message]
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 ` [PATCH net-next 12/15] tipc: Prevent loss of fragmented messages over unicast links Paul Gortmaker
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-8-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).